Server Help

Trash Talk - Spectate-Only-Client

Qndre - Sun Jan 25, 2004 8:55 am
Post subject: Spectate-Only-Client
I want to write a new Continuum client and combine it with my self coded webserver to make users (who don't have the Continuum client) able to spectate the game using their webbrowsers. So the program should recieve the data from the "Shanky Server", render it to an image file and send it to the browser there a plugin is running, which recieves the (very very compressed) image data from the server, decompresses it and puts it on screen, so everyone, who has a browser can spectate a game. The software logs in with the user Name "Spec0###". ### will be replaced with a random number, at example 589, so it's "Spec0589", the password is something, which doesn't change. The machine ID should be random, for example "7894". Then the software should spectate the game, get the image-data from the "Shanky-Server", render the wanted areas of the map and send it to the people who are spectating with their web browsers. But I need the protocol, which subspace uses (yes, it uses UDP) so that I can understand if the server sends 010111010100010011101010000101101010101000010101110101111010001011010 this means "the bomb level 2 is fired with 200 pixels/second speed and proximity bombs into direction with 45°, ...", you know what I mean! Thanks, Qndre!
ExplodyThingy - Sun Jan 25, 2004 12:44 pm
Post subject:
Snrrrubs site would be the place to check, but his server is kaput. Catid has a half-assed clone of his doc here : http://catid.ssihosting.com/files/SubSpace_1_35_Packet_Information.htm
I have a more detailed, though be it also incomplete, list at http://explody.ssihosting.com/misc/fpl/fpl.txt
Mine GO BOOM - Sun Jan 25, 2004 1:08 pm
Post subject:
The problem with this method is, that all clients only get position data around them only. So if you are specating around E6, you won't see anyone at J12. The only realistic way to do this is via a plugin for ASSS, a new server software, that still is in beta.

That can allowing a process on your server to connect to the server, without ever "logging in" like a normal client would, and receive information about where people are. This can then allow the process on your webserver to update a database or something, in which another script would be able to make realtime images of what the map looks like, which different freqs or players being different colors of the user's choice. Since this would be a custom made software, you could add in chatting systems, but that would be a bit more difficult, because you'll have to have some system of making chat-clients safely talking to people, but still be able to be secure from screwing around with other people in game (ie: spamming, harassing).
Fuzzjdc - Mon Jan 26, 2004 5:59 am
Post subject:
I posted a bot made by catid ages ago that has the ability to actually view the game. But it would require a lot of attention to actually get it to work.
50% Packetloss - Mon Jan 26, 2004 6:54 am
Post subject:
the big face avatar is driving me nuts, here are some ok ones
http://www.palace4all.de/avatarpage/index.php3
Qndre - Mon Jan 26, 2004 8:08 am
Post subject:
1. Thanks to ExplodyThingy - you helped me much. But I also have to download the map file (LVL)and the LVZ so I can render the graphics because they aren't all the same in different zones. A method how the LVZ is transferred and how I can decode the files (images, sounds) out of the LVZ would be useful. I would also need a way to decode the map file (LVL) into a common bit-map or image so I can take a piece out and blit the ships on top of it.
_
2. MineGOBOOM's reply:
"The problem with this method is, that all clients only get position data around them only. So if you are specating around E6, you won't see anyone at J12. The only realistic way to do this is via a plugin for ASSS, a new server software, that still is in beta."
But MineGOBOOM - there are two reasons why it should work: First you can recieve RADAR and MAP-Data from all parts of the level so there may be a way to get the ship's positions. And even if you can't spectate all parts of the map simultanously, there is a way out. So I can capture one frame from the area "User1" wants to see and the second frame from the area "User2" wants to see. And if that doesn't work I can create a user-login for all the users, who spectate the game. So there is one client running for "User1" and another client running for "User2" and so on. (yes - there is a way to log in with multiple clients simultanously - already tried it out) Another quote: "That can allowing a process on your server to connect to the server, without ever logging in like a normal client would" - but with that I could only login at my own server but not at any other zone, like DSB at example. :(
_
3. Fuzzjdc - thanks for your reply. If you could give the source to me, that would be great. (I hope the source isn't longer than 50 lines and is written in BASIC or PHP - NO C SOURCE PLEASE.)
_
4. Thanks to EVERYONE, who replied - these were the fastest replies I ever got in a forum. Thank you very much. Your replies are very useful.
_
5. I heard that the server wants security checksums from the client. How can I fake/generate them?
Mine GO BOOM - Mon Jan 26, 2004 10:04 am
Post subject:
Some problems I see in the way you wish to go

  1. Want to spectate areas people wish to see.

  2. Want to log into any zone to watch.

  3. You want to do this in BASIC or PHP

I'm sorry to shoot down your idea, as it is a good one, but impractical. The following are the only real ways I can see this happening:
  1. Running a bot off your own machine or a person who would host it for you.

  2. Running a plugin on an ASSS server (which no 'large' zone uses yet).

ExplodyThingy - Mon Jan 26, 2004 10:38 am
Post subject:
Qndre wrote:
3. Fuzzjdc - thanks for your reply. If you could give the source to me, that would be great. (I hope the source isn't longer than 50 lines and is written in BASIC or PHP - NO C SOURCE PLEASE.)


You have got to be kidding right? There are numerous open source bots out there. Mine is at explody.ssihosting.com/misc, Admiral Kirk has one at kirk.sscentral.com (dead dns), catid has one at catid.ssihosting.com. There is a limited-release Java bot out there too. At catids site you will also find an old VB bot. Most of these approach several thousand lines of code. My bot might be the simplest to understand as its pretty crude, undeveloped, and bare-necessities only.
50% Packetloss - Mon Jan 26, 2004 12:14 pm
Post subject:
"The page cannot be found"==the links to your bot's source/binaries plody
Qndre - Mon Jan 26, 2004 12:29 pm
Post subject:
50% Packetloss wrote:
"The page cannot be found"==the links to your bot's source/binaries plody

That's right. The server is currently down. But I've got a backup from that website. Sorry. I can't post it as an attachment because it's a 715 kilobytes PDF-File.
Qndre - Mon Jan 26, 2004 12:47 pm
Post subject:
Hello, MineGoBoom.
_
1.
Quote:
This shouldn't be too much of a problem, as your real-time specing probably won't be updated every 0.1 seconds. Do you plan on having only a radar-view of the map, or actual detail of people's ships, their direction, etc like you were watching with a real client?

I want to see the level and the complete shipset, bullets, greens, flags, bombs, etc. like I would spectate the game using the Continuum 38 client. (The client should be similar to Continuum 38.) The update-rate should be between two and five frames per second (four should be average).
_
2.
I will need the Continuum-encryption, because I want to write a Continuum-client and not a Subspace-client. But the "encryption" as you call it isn't really an encryption but a checksum system which should be easy to trick (there is a formula with the key on the internet).
_
3.
Quote:
I doubt it has the needed system calls to even do UDP packets, but that is just a guess.

There is a way to send UDP packets. It's a library called the "Windows Socket Controller".
_
4.
Quote:
Running a plugin on an ASSS server (which no 'large' zone uses yet).

No way!
_
5.
I've got a library to decompress the data out of the LVZ the client gets.
_
Summary:
You see - it shouldn't be a real problem. It won't be easy but I am confident I can do it.
_
PS: If I have finished I will put a "thanks-to"-line into the application with your names.
ExplodyThingy - Mon Jan 26, 2004 1:01 pm
Post subject:
Qndre wrote:
2.
I will need the Continuum-encryption, because I want to write a Continuum-client and not a Subspace-client. But the "encryption" as you call it isn't really an encryption but a checksum system which should be easy to trick (there is a formula with the key on the internet).

This will not happen. ANd it is a true encryption of the data. No one here has yet cracked it, and the author/creator whatever will not release it.

Im fixing my link now.
Smong - Mon Jan 26, 2004 3:06 pm
Post subject:
I don't think the many zones will allow your client to enter. I certainly wouldn't without a good reason.

I wouldn't want to be associated with a project with beginnings like this (talking about faking checksums and such), even if it went commercial.
Anonymous - Mon Jan 26, 2004 3:33 pm
Post subject:
ExplodyThingy wrote:
No one here has yet cracked it, and the author/creator whatever will not release it.

1. The author of the Continuum client is PriitK. He won't publish the source, that's right. But the server checks these security checksums and Shanky ALREADY HAS released the sourcecode because there are already other clients for Shanky-Server and Continuum (just check the clients for Linux, at example Srrrubspace, which are not created by PriitK).
2. There are some people, who already cracked the checksum/encryption-system and published the algorithm on their websites. The client builds a checksum of the "subspace.exe", does some other encryption-like-things and finally adds some time-codes and hardware-fingerprints (I will set the hardware-fingerprint to a random number for my client) to it. The complete algorithm can be found on bot-related websites like those of the MERVbot server system.
Qndre - Mon Jan 26, 2004 3:38 pm
Post subject:
I was the author of the "guest"-thread, which was posted 26th January 2004, 21:33. (THE TIME IS GMT + 1) I wanted to log in but the forum didn't take it. Sorry!
ExplodyThingy - Mon Jan 26, 2004 3:54 pm
Post subject:
Continuum uses an enhancement of the VIE alg. There are two diferent schemes out there. All the bots, even merv, my own, logic bot, and others, use VIE's scheme. We can assure you that continuums encryption method is not public.
Cyan~Fire - Mon Jan 26, 2004 5:41 pm
Post subject:
OK, well, you're not going to crack the Continuum encryption, so forget about that. The alogorithm that has been cracked (the one in MERV) is Subpsace encryption, not PriitK's Continuum encrytion. If you actually want to code a new client, you'll have to make a deal with PriitK. And that probably won't happen because if someone's trying to recode Continuum in BASIC, they can't be serious.
Not trying to be mean here, but Continuum would be basically impossible to do in BASIC.
50% Packetloss - Mon Jan 26, 2004 8:17 pm
Post subject:
Encryption is something that interests me but currently is beyond the programming knowledge that I posses. Explain to me why someone who read ASM couldn’t disassemble the continuum.exe and locate/figure out the code that is associated with encryption. There are c++ decompile programs (although I doubt they work well) that would aid in finding the location of the code.
Mine GO BOOM - Mon Jan 26, 2004 9:20 pm
Post subject:
Because some programs are actually encrypted themselves. The computer can decrypt it, but its a pain to do a good bit of the time, because its the program decrypting parts of itself on the fly. So this isn't something you can easily do, on the fly.

Also, as Priitk is (sometimes) alive, if someone does manage to get the code for it (which I must say, was a pain to get to work in the first place, even with his help), he can just change it and you'd have to go through the whole steps completely anew.
Anonymous - Mon Jan 26, 2004 10:11 pm
Post subject:
but i doubt he would... heh
nintendo64 - Mon Jan 26, 2004 10:43 pm
Post subject:
In my experience with dealing with people in SubSpace Development, i will just say this, if you are going to do something just do it, and if you need help, just ask the questions and wait for the answer, but never say your project here, because it will never be taken as a finished product, and the reason is a lot of players before have offered the same ideas and said they would make them and have never made them.

Good Luck, althought i am very doubtful you'll get throught too.

-nintendo64
Anonymous - Tue Jan 27, 2004 9:27 am
Post subject:
Mine GO BOOM wrote:
Also, as Priitk is (sometimes) alive, if someone does manage to get the code for it (which I must say, was a pain to get to work in the first place, even with his help), he can just change it and you'd have to go through the whole steps completely anew.

1. He won't do that because then all the server systems (even Shanky's one) would have to be rewritten.
2. The Continuum-encryption is 16-bit (64000 different keys) so a computer can crack it within some seconds.
Qndre - Tue Jan 27, 2004 10:06 am
Post subject:
ExplodyThingy wrote:
Continuum uses an enhancement of the VIE alg.

I know. I even know the formula it uses. It's on the web.
Anonymous - Tue Jan 27, 2004 10:09 am
Post subject:
Cyan~Fire wrote:
OK, well, you're not going to crack the Continuum encryption, so forget about that. The alogorithm that has been cracked (the one in MERV) is Subpsace encryption, not PriitK's Continuum encrytion.

Subspace and Continuum is 90% the same. You can still join the old subspace zones using the new continuum client. If the algorithm was another one, you weren't able to do so.
Qndre - Tue Jan 27, 2004 10:11 am
Post subject:
I am also the author of the "Guest" thread of 27th January 2004, 16:09 GMT+1. I hate these "forum-does-not-login-errors". icon_mad.gif
ExplodyThingy - Tue Jan 27, 2004 10:12 am
Post subject:
So go crack it. None of us have it. There is only two server platforms out there, and updating is not hard. Its done very easily and efficiently, updates do occur, after all. We're all aware of the details of the algs, we all know essentially how it functions, but none of us have cracked it, for want of motivation. SO get to it and impress us all.
Qndre - Tue Jan 27, 2004 10:32 am
Post subject:
Quote:
we all know essentially how it functions

So if you know how if works the only thing you need is the key which it uses to crypt.
_
For making it simple I will explain a simple algorithm here. The thing we know is that the server sends "10101010" as unencrypted data and the data and the key is combined using XOR operation and the result of the encryption is "01101001". Now I demonstrate how to get the key:

data(unencrypted) xor data(encryption)

10101010
01101001
-----------
11000011

Now we know the key is "11000011" and if we get the next encrypted packet and we know the data in it is "00111001" then we know that it's something like "xxxxxxxx" unencrypted: icon_confused.gif

00111001
11000011
-----------
11111010

And we know that the next data packet is "11111010" unencrypted. And a 16-bit-key shouldn't be too hard to crack. icon_cool.gif

And then we can calculate all the encrypted values of the data packets so we don't need to decrypt them one by one because we already use the decrypted values in our decoding-table. biggrin.gif

And I know that the unencrypted value of the "encryption-key"-packet from client to server is 0x0001 and then it gets the Type-Of-The-Key and then the Key-Itself and then the Client-Version. The last one should be set to 038 so that the server knows: "Ah - it's a Continuum 38 client!"

And for the CHECKSUMS we need we only have to add every single byte of the application file "subspace.exe" together. Finished! sa_tongue.gif jb_google.gif
ExplodyThingy - Tue Jan 27, 2004 10:39 am
Post subject:
Dont yell at me you miserable fuck. Looks like youre smarter than me, and know more about what youre doing. So I guess Ill just stop posting here. Maybe you should go and figure it out. When youve got a client connecting and making the server think youre continuum, come back, Ill give you a cookie.
Qndre - Tue Jan 27, 2004 10:41 am
Post subject:
You will get the complete algorithm if I've put the information together.
Anonymous - Tue Jan 27, 2004 11:03 am
Post subject:
Now I know how the algorithm works:
Quote:
The client sends the request of the key to the server. The server gives the client the key (the server uses a random but unique key) and every data which is send from the client to the server or from the server to the client is en-/decrypted using XOR operation and the key.
[/quote]
Qndre - Tue Jan 27, 2004 11:08 am
Post subject:
Quote:
You miserable fuck. Looks like youre smarter than me, and know more about what youre doing.

I don't know if I am smarter than you because I don't really know you and I've never said anything like that or wouldn't even say anything like that even if it was true. I only wanted to get some extra information about Continuum. After the first replies (with the link to Explody-Thingy's server site) I've known enough to build a full client like Continuum38 is today. I'll shut up now if you don't want to hear how it works... and I don't think you really want because if you talk to me in this way you can't be really interested in my work. See you later. I won't tell you.
Smong - Tue Jan 27, 2004 11:20 am
Post subject:
Shanky-Server/Continuum server what are they? shanky.com/server is just a place to download the latest server.zip. The current server is subgame2, it has been edited to work with fix.dll which contains all the anti-cheat stuff and new features since 134.

What you have written looks suspiciously like one of catid's docs, but re-phrased. And anyone writing encryption wouldn't do a simple XOR, they would throw some other tweaks in there as well.

As for no one knowing the workings of ctm encryption, no comment, if too much attention is drawn, it is not hard to change it. Don't cry wolf. Don't spoil a good game people have put lots of their free time into.
Qndre - Tue Jan 27, 2004 12:00 pm
Post subject:
Hi Smong. The "shanky-server" is a software package. It includes the "subbill.exe" (Subspace Billing Server) the "subgame2.exe" and all its components (Subgame 2), an LVZ-toolkit ("buildlev.exe") and the latest version of the MERVbot ("mervbot.exe").
Qndre - Tue Jan 27, 2004 12:02 pm
Post subject:
Smong wrote:
And anyone writing encryption wouldn't do a simple XOR, they would throw some other tweaks in there as well.

Every good encryption works with XOR statements. Even the almost-uncrackable MD5 (128-bit hashing - used for password encryption) works with XOR. It takes the data and rotates the next byte just one bit more to left and then XORs them all and finally XORs with a constant.
Smong - Tue Jan 27, 2004 12:14 pm
Post subject:
Is English your first language? You seem to be having difficulty understanding what is written before you. I said "simple XOR". I hardly think encdata[i] = data[i] ^ table[(i++)%sizeof(table)]; for "almost-uncrackable MD5".

I just went to shanky.com/server and could not locate this elusive "shanky-server" package. I did however download server.zip, only to find the only new thing in there since I last checked is tracert.exe. I even dug around SSDL, nothing like "shanky-server" there.
Qndre - Tue Jan 27, 2004 12:19 pm
Post subject:
server.zip IS a part of the Shanky-Server. Just download the MERVbot and the LVZ-Toolkit, too and you have the package, which is called "shanky-server" (at example if they talk about it in the Zone DSB). It is no special file. Just download all the components and you have a "shanky-server". If you talk to one then if you say "I've got a shanky-server" it's much quicker than if you said: "I've got the subbill.exe and the subgame2 server and the MERVbot and the LVZ-Toolkit running on my server." Because this is a very common server-configuration it's called "shanky-server" so that you don't have to tell the components every time. That's all. biggrin.gif
_
About my English: I am from Germany, sorry.
50% Packetloss - Tue Jan 27, 2004 12:23 pm
Post subject:
<3
Qndre - Tue Jan 27, 2004 12:27 pm
Post subject:
I should reply to an empty reply? icon_eek.gif
*joke-around* biggrin.gif
_
PS: Creating a full Continuum38-like client won't be simple. That's sure. But it's possible. And even if no one else had cracked the encryption yet someone has to be the first.
nintendo64 - Tue Jan 27, 2004 12:37 pm
Post subject:
I will say this much, Continuum encryption has been cracked in the past (versions 0.35, 0.36 and 0.37), but i doubt you will crack, maybe if you showed some more code and talked a little less, you should take the advice i posted up.

When Coconut Emulator cracked the SS encryption he didn't say it on a board and he didn't even said he would, why? because he wasn't sure he could do it, now SS encryption is not that hard (it was a scheme with a 4 byte key, that's why there were some extra security like the Position Checksum and the Securiry Checksums), but CTM is another case.

Here is a sample of the CTM Login Sequence.

Note the 00 01 Core Packet.
After this everything becomes blurry, even Packet headers are encypted.
0000 00 01 4F DA 77 97 11 00 ..O.w...


0000 00 10 00 00 DA 7F A9 6F BA EA 01 00 .......o....
0000 00 11 00 00 DA 7F 01 00 ........
0000 5C 14 BC 78 85 F6 74 EA \..x..t.
0000 7F 63 30 .c0

You catch what i mean?

-nintendo64
Qndre - Tue Jan 27, 2004 12:42 pm
Post subject:
Yes, I will shut up and tell you if I've done it.
nintendo64 wrote:
INote the 00 01 Core Packet.
0000 00 01 4F DA 77 97 11 00 ..O.w...

If I knew a bit more about network protocols...
Smong - Tue Jan 27, 2004 12:59 pm
Post subject: Re: Spectate-Only-Client
Qndre wrote:
I can understand if the server sends 010111010100010011101010000101101010101000010101110101111010001011010 this means "the bomb level 2 is fired with 200 pixels/second speed and proximity bombs into direction with 45°

Taken out of context a bit ... heh
Anonymous - Tue Jan 27, 2004 1:01 pm
Post subject:
*laugh*
It was just an example.
Qndre - Tue Jan 27, 2004 1:16 pm
Post subject:
Quote:
even packet headers are encrypted

How can you see that the headers of the packets are encrypted? I only see a hash of hex-numbers at my screen. I tried to track the login sequence of C38 client but I don't know much about networking protocols. And if I can't decrypt the Continuum packets, how can I generate a VIE-checksum to write a VIE-client?
Quote:
open sourced everywhere
(searched Google after "VIE Checksum" or "VIE Source Code" or "Subspace Source Code" or "VIE Subspace Source Code" - not the wanted results) And if I was able to fake VIE-Checksums... Will this client still be able to use features of Continuum (like LVZ at example) or will the server act like "this is no continuum client so it doesn't need the LVZ"?[/quote]
ExplodyThingy - Tue Jan 27, 2004 2:00 pm
Post subject:
The VIE Client itself is not open source. But there are many bots that use the VIE scheme, as I posted earlier. I dont think you quite understand that VIE used a diferent system than what is now in use in Continuum. When n64 said that the packet headers are encrypted, he meant the first bytes, the ones that signify what type of packet it is. This would be the hex value at the very start, and you can see these in the doc I provided you.
In all of the bots there is a fully functioning VIE checksum ripoff, this does the checksums against a VIE client. However, continuum is not subspace.exe. Also in all of these bots is the entire encryption method, so start from there.
All clients that login fully will recieve the object control data, and other "recently" added data. Older clients simply discard them or throw some kind of error. You can see this because bots can recieve object data even though they are on a older encryption.
ExplodyThingy - Tue Jan 27, 2004 2:25 pm
Post subject:
Maybe this will help you:
http://catid.ssihosting.com/files/addendum.txt
Anonymous - Tue Jan 27, 2004 2:49 pm
Post subject:
ExplodyThingy wrote:
All clients that login fully will recieve the object control data, and other "recently" added data. Older clients simply discard them or throw some kind of error. You can see this because bots can recieve object data even though they are on a older encryption.

So I can log in to a Continuum-Zone with the VIE-client. But how does the VIE-encryption work? And WHY do they ENCRYPT game data??
Qndre - Tue Jan 27, 2004 2:50 pm
Post subject:
Thanks ExplodyThingy - the most important parts:
Quote:
There are some ways to disable encryption:

Send a KK field of 0. 00 01 00 00 00 00 01 00
The server must respond with a NULL key (no encryption).
Custom SubSpace stacks may ignore this.

Encryption may be disabled server-side if the key you send
is the same as the key you get back.

Quote:


This method of encryption is very weak...
If you know PLAINTEXT
then PLAINTEXT ^ CIPHERTEXT = SECRETKEY. (^ = xor) In short, do not trust any
personal data on a logged connection to SubSpace.

Quote:
Continuum key exchange:
00 10 - Server keys
00 10 <Key1(4)> <Key2(4)>
00 11 - Client acknowledgement
00 11 <Key1(4)>

Quote:

-=Security checksums=-
These have been hacked for SubSpace. You may find pretty C++ classes that do the nitty-gritty in
MERVBot's encrypt.cpp and checksum.cpp files.

Thanks to ExplodyThingy
Smong - Tue Jan 27, 2004 3:18 pm
Post subject:
You yourself said encryption was a simple XOR, isn't that how VIE-enc works?

Stuff is encrypted so that people cannot play through a proxy that conveniently inserts packets on certain keystrokes, for example requesting all the flags.

I think there are 3 server options regarding VIE-enc, either allow it to connect and play, allow to connect but spec only, or dissallow the client from entering the zone completely.

If you happend to be on the VIP then I think you can use any encryption, but you must return correct checksums still. I read somewhere the the recent server releases no longer support 'no encryption', unlike the subgame.exe found on the SS CD (available at SSDL). When I was making my bot I used the old server as I didn't want to mess with encryption. Another thing is the reliable packet stack, cluster packets and chunked packets, those can be just as hard to clone as encryption.
Qndre - Tue Jan 27, 2004 3:27 pm
Post subject:
No one in this forum has to argue about if I've got enough skills to do it or not. I also don't know it. I want to try so I'll try. At the moment I am very busy so I'll begin this project on the weekend. I'll start simple. Create a VIE-session on my own shanky-server and destroy it. Then I can try to download the LVL and convert it to an image,... I'll try it step by step. Then I'll see if there are any problems. (I expect there are because there always are problems if you're writing a program) Thank you all very much.
Quote:
You must return correct checksums still. Another thing is the reliable packet stack, cluster packets and chunked packets, those can be just as hard to clone as encryption.

How can I generate these checksums? Out of the file "subspace.exe"? What's a "reliable packet stack"? I know what "clustered packets" are, but what are "chunked packets"? Isn't is the same?
Mine GO BOOM - Tue Jan 27, 2004 3:42 pm
Post subject:
There is only one emoticon in which can express what I feel when I'm reading this thread:


Smong - Tue Jan 27, 2004 3:44 pm
Post subject:
A chunked packet is where there is too much data to fit into one packet. A reliable stack is needed because UDP is unreliable, when you receive a packet tagged as reliable you must send an acknowledgement to the server. This 'tag' contains certain info that means you must acknowledge packets in a certain order and discard others.

Even if you don't complete your desired project, perhaps you could turn it into a nice map + lvz editor?
nintendo64 - Tue Jan 27, 2004 6:55 pm
Post subject:
That's a nice emoticon, i think i will save it to use it sometime later icon_smile.gif

-nintendo64
Fuzzjdc - Tue Jan 27, 2004 9:54 pm
Post subject:
has anyone thought to examine the fix.dll with the subgame2.exe? it might be interesting...
Dr Brain - Tue Jan 27, 2004 11:55 pm
Post subject:
Mine GO BOOM wrote:
There is only one emoticon in which can express what I feel when I'm reading this thread:



Almost as good as that Thread Reanimator one. Keep 'em coming. icon_wink.gif
Qndre - Wed Jan 28, 2004 7:01 am
Post subject:
Smong wrote:
A chunked packet is where there is too much data to fit into one packet. A reliable stack is needed because UDP is unreliable, when you receive a packet tagged as reliable you must send an acknowledgement to the server. This 'tag' contains certain info that means you must acknowledge packets in a certain order and discard others.

Even if you don't complete your desired project, perhaps you could turn it into a nice map + lvz editor?

Maybe I can create a MAP- and LVZ-software which can download the MAP and LVZ from an existing zone and safe it to the harddisk (and perhaps upload the files after modifiing if you have SysOP rights).
Anonymous - Wed Jan 28, 2004 7:21 am
Post subject:
ya know the lvz file format??
Qndre - Wed Jan 28, 2004 7:25 am
Post subject:
Illetni wrote:
ya know the lvz file format??

No but I've downloaded a library which can decode the data on it. The file format which makes me crazy is the LVL format. How to decode it to an image file (like BMP is)...
D1st0rt - Wed Jan 28, 2004 12:44 pm
Post subject:
http://sourceforge.net/project/showfiles.php?group_id=22316&package_id=55692

this has all kindsa crap like packets, encryption, protocol, in c++ files
Qndre - Wed Jan 28, 2004 1:41 pm
Post subject:
Thank you very much, distort. That's the stuff I needed. Is the LVL-decoding included?
Mine GO BOOM - Wed Jan 28, 2004 3:50 pm
Post subject:
A simple search of "lvl" on the forums resulted with the thread in which I explain LVL structures in great detail.
Qndre - Thu Jan 29, 2004 10:18 am
Post subject:
Thanks, MGB. But it looks quite difficult. There is no easier way to decode it to an image??
Qndre - Thu Jan 29, 2004 12:38 pm
Post subject:
YES!! I found out (with the help of ExplodyThingy's document) how to build a login sequence for the Continuum client and disable encryption in it.
Code: Show/Hide

~~~ CTM login sequence without encryption ~~~
            (C) by Qndre
            Thanks to ExplodyThingy


C -> S   00 01 00 00 00 00 VV VV

S -> C   00 05 TT TT TT TT

C -> S   00 06 00 00 00 00 TT TT TT TT

S -> C   00 02 KK KK

C -> S   00 09 NN UU UU UU UU UU UU UU UU UU
               UU UU UU UU UU UU UU UU UU UU
               UU UU UU UU UU UU UU UU UU UU
               UU UU UU YY YY YY YY YY YY YY
               YY YY YY YY YY YY YY YY YY YY
               YY YY YY YY YY YY YY YY YY YY
               YY YY YY YY YY RR RR RR RR 00
               00 01 00 00 VV VV 04 44 05 55
               00 00 00 00 00 00 00 00 00 00
               00 00 00

S -> C   00 06 PP PP PP PP TT TT TT TT 00 0E LL ... 00 03 II XX ...



VV      = Version (0x24 = PriitK / 0x86 = VIE)
TT      = Timestamp
KK      = Encryption-Key (0x00 because first Core-Packet disabled it)
PP      = Ping
LL      = Level-File
II      = ID
XX      = Anything (not known)
NN      = New User (00 = Not-New; 01 = New)
UU      = Username
YY      = Userkey
RR      = Random

50% Packetloss - Thu Jan 29, 2004 1:18 pm
Post subject:
Once you convince the server that you logged in on a conti client, can you then start using SS encryption to send all the other packets? Just from what I have read in merv's code, the bot seems to just tell the server its location and then its able to jump there. I have to pick up a book on winsock to understand this stuff, but it seems to me that once you can login as a contiuum client, then you could easily cheat. Maybe it isnt so wise to post your findings? Just email minegoboom about what you find?
nintendo64 - Thu Jan 29, 2004 2:33 pm
Post subject:
Qndre, what you say actually doesn't works on ForceContinuumOnly Zones, i know this, but i decided to try.

00 01 Encryption Request Packet with the Continuum Encryption version 11 (VIE is 1)
I did the 00 01 00 00 00 00 11 00
I got a reply of 00 10 Packet an ACK used to start the Encryption Sequence which i cannot start with the VIE Encr scheme i got on my bot.

Then i tried a
00 01 Encryption Request Packet with the SubSpace Encryption Version 01 (CTM is 11)

i did 00 01 00 00 00 00 01 00
i didn't get any reply, the Subgame let my SS Bot on hold.

btw 0x24 is 36 you should use 0x27 which is 39 and 0x86 is 134.

Also do a *einfo on the application you did the Login session, you won't see a CTM if you logged in with a Sysop Password, it will say VIE 0.36 on your case because you used 0x24, if you had used 0x86 it'll say 1.34.

A note here Sysop can enter with a SubSpace Client to force only Continuum zones.

Well good luck trying to figure out a Continuum Session.

-nintendo64
ExplodyThingy - Thu Jan 29, 2004 6:02 pm
Post subject:
Just a note, Im glad I can help and all, but that document on the ss protocol (the second one I gave you) was written by catid. Check the last line of the file. The other document, the protocol list (the first one I gave you), was written by me but only as a combination of other people's work.

Please be sure to give them credit as well.
Qndre - Fri Jan 30, 2004 12:19 pm
Post subject:
ExplodyThingy wrote:
Just a note, Im glad I can help and all, but that document on the ss protocol (the second one I gave you) was written by catid. Check the last line of the file. The other document, the protocol list (the first one I gave you), was written by me but only as a combination of other people's work.

Please be sure to give them credit as well.

Yes.
Just made my client able to send victory-packets to the server. So I can make the server give out a victory request and start victory music and give "Qndre makes a victory" message. (tried in Death Star Battle) But they didn't give victory-points to me. The mods didn't recognize my action. *i'm glad*
Qndre - Fri Jan 30, 2004 12:49 pm
Post subject:
No. I wasn't able to do the action discribed above. It only took effect at local client but not at the others. icon_sad.gif It isn't as easy as I thought.
Smong - Fri Jan 30, 2004 1:01 pm
Post subject:
I am unaware of any gametype in SS that plays victory music and says "<name> makes a victory". Scoring a goal displays the player's name. Holding all the flags starts the music. Two different things.

@50% Packetloss
That is why public bots use VIE encryption, so the ops can control who can and can't login.
Qndre - Fri Jan 30, 2004 2:16 pm
Post subject:
Smong wrote:
I am unaware of any gametype in SS that plays victory music and says "<name> makes a victory". Scoring a goal displays the player's name. Holding all the flags starts the music. Two different things.

@50% Packetloss
That is why public bots use VIE encryption, so the ops can control who can and can't login.

Just look at DSB. They do. They don't say "<name> makes a victory", but "<team> makes a victory". They do so if you hold all the flags for five minutes. And if you hold all the flags and the five minutes aren't over the victory music is played.
ExplodyThingy - Fri Jan 30, 2004 3:46 pm
Post subject:
Actually, thats not why. Thats a perk icon_smile.gif The reason is that no one has the motivation to fake a continuum connection, or even the need to. VIE encryption sustains the bots, they have so far lasted just as well as a client with the new scheme.

But, this is just returning to the original statements and therefore making a circular agruement.

Try simply sending a chat message, or a drop-koth. Later you can try faking a ship, then requesting the flag.
Qndre - Fri Jan 30, 2004 4:59 pm
Post subject:
ExplodyThingy wrote:

Try simply sending a chat message, or a drop-koth. Later you can try faking a ship, then requesting the flag.

Drop-KotH? What's that? I know something about King-Of-The-Hill but it's very complicated. But how can you "drop" a KotH?
ExplodyThingy - Fri Jan 30, 2004 8:59 pm
Post subject:
Its a packet. And is pretty simple system. I just dealt with a guy who didnt know whether or not he was on dialup so I dont think Ill be going into detail right now.
CypherJF - Fri Jan 30, 2004 9:27 pm
Post subject:
poor explodythingy icon_smile.gif
Anonymous - Sat Jan 31, 2004 4:07 am
Post subject:
I don't know enough about encryption to try and crack some arbitrary method, but I do know that if it's custom it is likely to be weaker than open and tested methods. This means that either a) it's a relatively simple task or b) an existing method is used.

I also know that it is possible to agree upon an encryption key without passing enough information across the wire to allow someone to obtain it. Google for Diffie-Hellman key exchange, it's simple enough. That rules out proxies as a cheat mechanism with the exception of Man-In-The-Middle style connections and throws it back to local memory modifications.

As for MITM attacks, as far as I know, there is no way to prevent a MITM attack with one willing participant. Perhaps the only thing you could do would be to hard-code RSA keys into the client and have a secure remote server sign the zone IP lists, with the client sending a specific identifier when connecting to IPs verified in that list.

But this is still thwartable with some more work, or a NAT setup! But it's certainly more annoying eh?

Perhaps Cont client&server simply need a code update so they work differently.


Still, this whole security-through-obscurity kick with things like the Continuum protocol and certain bots etc. is really rather annoying. I'd like the whole deal a lot better if it was open sourced. All it does is stunt development IMO.

What if the entire thing was open-sourced minus the current encryption code? Are there enough interested programmers to take it in hand and beef it up against cheaters in a way that's still open and accessible to third party projects of interest like the one that started this thread?

Why doesn't anyone seem to find it desirable for random people to contribute useful (or useless) programs of their own to the Subspace "effort" as a whole?
nintendo64 - Sat Jan 31, 2004 12:37 pm
Post subject:
You can find some debates about what you want at

http://www.ssforum.net/index.php?showtopic=84

http://www.ssforum.net/index.php?showtopic=273

In the SSForum Board.
http://www.ssforum.net/index.php?act=idx

-nintendo64
Mine GO BOOM - Sat Jan 31, 2004 2:37 pm
Post subject:
Argh. For people who are trying to make bots, you sure don't look at other people's code very much for ideas/logic. Do you know what the point of the Continuum encryption is? To tell the server that this is a user client, not a bot, and not someone who could possibly be using Twister.

Using that encryption method instead of the VIE encryption only changes VERY little of the actually packets sent between the clients. The Continuum client can respond with the SSC Billing's little zone checksum, saying if its an 'approved' zone, or if its anyone elses. In fact, the VIE client can respond with that, if programmed to, but only one person knows what the information means; Priit. He made the SSC billing, he made the client. So, thats a pretty secure zone checksum for that reason, even ignoring the fact that no one has access to half of the executable code for it.

Using this encryption also changes if you get LVZ info or not. VIE encryption will tell the server that this person doesn't need to know about LVZ, so don't bother sending it to him. If you really want this information, you can change ASSS to always send it to everyone.

That is it. Every other packet is sent to both VIE and Continuum clients. Even those only Continuum uses, such as the *warpto packets and such. So, using the Continuum encryption instead of VIE does very little for you.
Qndre - Sat Jan 31, 2004 5:11 pm
Post subject:
Yes!! biggrin.gif
Sent 00 01 core packet to the server with 00 00 encryption key. Server didn't respond. Sent 00 01 core packet again this time with FF FF encryption key. Server responded, gave me a timecode and asked for my timecode. I sent server's time code back but he didn't respond. How do I generate a valid timecode and pingtime?
ExplodyThingy - Sat Jan 31, 2004 6:17 pm
Post subject:
Ok, look in any of the numerous open sourced bots out there. For examply, explody.ssihosting.com/misc/explbot/explbot-src.zip

So, just pay attention.
Mine GO BOOM - Sat Jan 31, 2004 10:00 pm
Post subject:
Once you send the your clock (in C, it would be GetTickCount() / 10), you then send your login packet.

I suggest you log a few other bots logging into zones a few times, to get a feel for how the protocol works. Myself personally, I've spent atleast 50 hours (maybe upto 100) pouring over packets logged and printed out, without knowing anything about the protocol at all. Figured out about 90% of everything then. Encryption (which Eris was kind enough to help me with) and the ball packets where the few things I wasn't able to do myself.

Never under estimate the power of a really boring math class in High School.
D1st0rt - Sat Jan 31, 2004 10:59 pm
Post subject:
thats how I learned to make calculator programs in 8th grade
ExplodyThingy - Sat Jan 31, 2004 11:41 pm
Post subject:
Calculators icon_smile.gif

You can easily activate the packet logger on my bot. Search out LogComms, and make sure they are all uncommented. Look the in the logcomm function itself, and you can see if it logs out the terminal or to the file. Usually does both.
Anonymous - Sun Feb 01, 2004 2:56 am
Post subject:
I follow what you mean but I think you missed part of what I was saying icon_wink.gif I'm not saying there's a difference in functionality; I'm just saying it's a bad idea to think it's secure just because you don't know of anyone who has 'broken' it yet. Also, although there are more straightforward ways of differentiating between a user client and a bot there IS no way to tell for certain. As things stand you can be pretty damn sure, but there are no guarantees.
Anonymous - Sun Feb 01, 2004 8:30 am
Post subject:
The server wants timestamps. How do I generate one?
Qndre - Sun Feb 01, 2004 8:34 am
Post subject:
Anonymous wrote:
The server wants timestamps. How do I generate one?

The reply was mine.
Smong - Sun Feb 01, 2004 9:17 am
Post subject:
Mine GO BOOM wrote:
Once you send the your clock (in C, it would be GetTickCount() / 10), you then send your login packet.

BTW, no need to to say 'the post above is mine', it gets annoying to other people.
Qndre - Sun Feb 01, 2004 9:51 am
Post subject:
What does this "clock" count?? The duration since sending the 00 01 core packet (connecting) or the time (like 4:30 pm at example)? The clock changes every second or every 1/10th or every 1/100th? Is it all seconds or hh:mm:ss or something like that? It also requires a ping time. What's that? Why doesn't he simply send a packet and I reply and then he knows the ping I have (like "ping" in command line does)?
Smong - Sun Feb 01, 2004 10:05 am
Post subject:
The tick count on windows desktops tends to be 1000 ticks per second. I think SS works with 100 ticks per second, hence the '/ 10'. The tick count is based on how long your computer has been switched on. That is why old subgame's that have been running non stop for a long time got confused with negative tick counts (using signed, instead of unsigned data types).

I'm not sure what this 'ping' thing is, last time I checked you sent the 0x01 login, server sent 0x02 response with the data from the 0x01 made negative and the tick count at the server side.
There is an 0x05 sync packet that includes the packets sent/received, is that what you meant about ping?
Qndre - Sun Feb 01, 2004 10:30 am
Post subject:
Smong wrote:
There is an 0x05 sync packet that includes the packets sent/received, is that what you meant about ping?

If the server sends this:
_
00 05 + (4 BYTES TIMESTAMP)
_
_
Then I'll have to respond with a 00 06 core packet and give the server my ping and timestamp. This will look like this:
_
00 06 + (4 BYTES PING) + (4 BYTES TIMESTAMP)
_
You know what I mean? If not then look at ExplodyThingy's packet list.
_
_
And I have to correct my login sequence. It's more like this:
_
Code: Show/Hide

~~~ Full CTM login sequence with encryption ~~~
            (C) by Qndre


C -> S   00 01 FF FF FF FF (2 BYTES VERSION)

S -> C   00 05 (4 BYTES TIMESTAMP)

C -> S   00 06 (4 BYTES PING) (4 BYTES TIMESTAMP)

S -> C   00 02 (2 BYTES KEY)

C -> S   00 09 NN UU UU UU UU UU UU UU UU UU
               UU UU UU UU UU UU UU UU UU UU
               UU UU UU UU UU UU UU UU UU UU
               UU UU UU YY YY YY YY YY YY YY
               YY YY YY YY YY YY YY YY YY YY
               YY YY YY YY YY YY YY YY YY YY
               YY YY YY YY YY RR RR RR RR 00
               00 01 00 00 VV VV 04 44 05 55
               00 00 00 00 00 00 00 00 00 00
               00 00 00

S -> C   00 06 (4 BYTES PING) (4 BYTES TIMESTAMP) 00 0E (x BYTES LEVELFILE) 00 03 (1 BYTE ID) ...


VV      = Version (0x24 = PriitK / 0x86 = VIE)
NN      = New User (00 = Not-New; 01 = New)
UU      = Username
YY      = Userkey
RR      = Random (MachineID)

_
_
_
_
nintendo64 wrote:

Here is a sample of the CTM Login Sequence.

Note the 00 01 Core Packet.
After this everything becomes blurry, even Packet headers are encypted.
0000 00 01 4F DA 77 97 11 00 ..O.w...

That's not right. If I send core packets to my server I get unencrypted responses like I would expect them. If I send a 00 01 core packet then I get a 00 05 response - UNENCRYPTED. The thing you showed:
Quote:

0000 00 01 4F DA 77 97 11 00 ..O.w...

There is no packet header visible because the 00 01 core packet is sent and then a "4F DA 77 97", which is the encryption key itself (I don't know when it gets used... I guess behind the login sequence because all the packets I got were unencrypted). And then it's a 11 00 and that's the version of your client. So of course it's "blurry" because you haven't seen any packet yet in these 8 bytes. It's only the 00 01 core packet and its variables.
nintendo64 - Sun Feb 01, 2004 12:22 pm
Post subject:
Qndre wrote:

There is no packet header visible because the 00 01 core packet is sent and then a "4F DA 77 97", which is the encryption key itself (I don't know when it gets used... I guess behind the login sequence because all the packets I got were unencrypted). And then it's a 11 00 and that's the version of your client. So of course it's "blurry" because you haven't seen any packet yet in these 8 bytes. It's only the 00 01 core packet and its variables.


....., i posted no only 00 01 core packet also what comes next which is:

0000 00 10 00 00 DA 7F A9 6F BA EA 01 00 .......o....
0000 00 11 00 00 DA 7F 01 00 ........
0000 5C 14 BC 78 85 F6 74 EA \..x..t.
0000 7F 63 30 .c0

Note: if you do Encryption version 11, you don't get unencrypted packets. In your server you probably might think you get unencrypted because you see headers, but Packet headers in the server are always unencrypted for the VIE Encr not CTM's.

-nintendo64
Qndre - Sun Feb 01, 2004 1:09 pm
Post subject:
The features my software should have:
_
- Work as a Webserver on port 1777 (Listen)
- Show Logo and Menu on Homepage
- Edit Server's behaviour by changing options (remote administration)
- Log into a Subspace VIE zone
- Show stats: Who dies which often? Who owns which flags?
- Show kill list: 10 last killers: Who was killed by who?
- Who is in the elimn room?
- Render Images
- Transfer images (every 5 seconds an image)
- Show a fixed area of the map
- Show a user-defined area of the map
- Transfer a continous movie (Videostream on demand / 4-5 frames per second)
- Follow a selected player
- Follow the action (the place where most bombs are)
- Transfer sound too (AV-stream on demand)
- Connect to Continuum-only zones.
_
The features should be added chronologically. So I will begin with a webserver. That's not easy because the webbrowser doesn't take my data yet. Don't know why but it doesn't. I'll have to debug and devellop much. This may take time. But it's fun. biggrin.gif
_
What is the difference between the server option "force continuum" and "allow vie clients"? What is if I set them both to "1" or both to "0"?
Qndre - Thu Feb 05, 2004 10:28 am
Post subject:
All about the TickCounter:
http://www.functionx.com/visualc/applications/tickcounter.htm
Cyan~Fire - Thu Feb 05, 2004 5:53 pm
Post subject:
Uhh that's instructions on using it an MFC app, which isn't necessarily all about it.

The real GetTickCount() documentation.
Qndre - Fri Feb 06, 2004 1:06 pm
Post subject:
Cyan~Fire wrote:
Uhh that's instructions on using it an MFC app, which isn't necessarily all about it.

The real GetTickCount() documentation.

Er... The documentation you gave is using Microsoft's C++ not Borland C, which Subspace is written in (Continuum is written in Borland's TurboPascal).
ExplodyThingy - Fri Feb 06, 2004 1:21 pm
Post subject:
I certainly hope you're joking....
CypherJF - Fri Feb 06, 2004 1:23 pm
Post subject:
^_^ newbs lol... icon_smile.gif.. oh wait i probably shouldnt entertain them ...
Mine GO BOOM - Fri Feb 06, 2004 2:20 pm
Post subject:
Qndre wrote:
Er... The documentation you gave is using Microsoft's C++ not Borland C, which Subspace is written in (Continuum is written in Borland's TurboPascal).


Umm.. the windows.h file is a standard, use by almost every C compiler for windows. So, GetTickCount() works the same in Visual Studios (its not called Microsoft's C++, as they didn't make it) as it does in Borland's C++ Builder.

As for your comment about Continuum being written in TurboPascal, I hope you are joking. It was written in C++. See the documentation below for more information about which version it was written in.
Qndre - Fri Feb 06, 2004 2:42 pm
Post subject:
Mine GO BOOM wrote:
[..]
As for your comment about Continuum being written in TurboPascal, I hope you are joking. It was written in C++. See the documentation below for more information about which version it was written in.

I am using RE-C, the great and well-known C-decompiler. It can almost decompile from any EXE file (doesn't have to be written in C) to C source but it has problems with TurboPascal's EXE files. If I try to decompile "Continuum" using RE-C I get the error message "REC - 139 lines left / can't decompile / this EXE file is written in TurboPascal / reverse engineering aborted"!!
Qndre - Fri Feb 06, 2004 3:04 pm
Post subject:
nintendo64 wrote:
[..]
Note: if you do Encryption version 11, you don't get unencrypted packets. In your server you probably might think you get unencrypted because you see headers, but Packet headers in the server are always unencrypted for the VIE Encr not CTM's.

I've got some questions about VIE encryption because everyone gives me other information and I can't try out everything. Well... Packet headers are unencrypted but the data which follows is encrypted? If I send data to the client do I have to encrypt it as well or is the server sending encrypted packets to the client and the client responds unencrypted? Which key do I have to use for what? If I look at the protocol document the server sends a key and my client sends a key. If you aren't behind the login sequence then packets are also encrypted? Where do I have to put my machineID? It can be random? What about the password? Does it use another encryption than the rest of the data? In the profile file the password is encrypted. Do I have to send this encrypted password or the plain-text? Is the encrypted or plain-texted password also encrypted using one of the keys? Using which one? Please just give me everything you know about it. (Already downloaded sourcecode of Subspace client but I don't understand because I am not able to do C.) Chunked packets and Filetransfer (LVL, LVZ) are also encrypted? I heard about reliable messages? I'll have to respond with an ACK. Is it encrypted? Are the security checksums encrypted? Are they using a different algorithm than the rest?
ExplodyThingy - Fri Feb 06, 2004 5:16 pm
Post subject:
This thread is a giant joke isnt it? If you are so earnest about this thing, you certainly have a LONG way to go. Try starting smaller.

Everything in the packet is encrypted except the header. The header is the first 1 byte (2 if core type). The packet is encrypted just before is it dispatched to the server, so if youre clustering a packet, nothing is encrypted untill just before its sent.

Decompiling and is not even remotely as effective as one thinks. You really dont need to reverse engineer anything new, its all out there for you.

Where do you put youre machine id? Read the docs, any packet description containing the machine id is where the machine id does.

Where exactly did you get (or think you got) ahold of the subspace source?

I think that Mr Ekted said it right on ssforum:
Quote:
If a kid comes to you with a toolbox and a pile of wood and says "I'm going to build a skyscraper. What do I do?", what are you going to tell him? "Maybe you better take some engineering courses first." That's about the most constructive thing I can say.

nintendo64 - Fri Feb 06, 2004 9:14 pm
Post subject:
Qndre wrote:
[..]


I am using RE-C, the great and well-known C-decompiler. It can almost decompile from any EXE file (doesn't have to be written in C) to C source but it has problems with TurboPascal's EXE files. If I try to decompile "Continuum" using RE-C I get the error message "REC - 139 lines left / can't decompile / this EXE file is written in TurboPascal / reverse engineering aborted"!!


Hrm, did you find that Continuum Binary is packed? did you unpack it before you used the C Decompiler? probably not, so there you go why it has that error.

Note: I know Continuum is packed, because i've got an unpacked version of it.

@Explody: thanks for replying him on that, i am tired..

-nintendo64
Qndre - Sat Feb 07, 2004 10:19 am
Post subject:
nintendo64 wrote:
[..]
Note: I know Continuum is packed, because i've got an unpacked version of it.

No doubt. You know about what you're talking. But how can the system execute a packed binary file? Every EXE-file (except 32-/64-bit files) is directly written into the CPU. How can the CPU execute the file if it's packed? If the CPU understands those packed opcodes then I guess RE-C also does, but I'm not sure.
Dr Brain - Sat Feb 07, 2004 11:27 am
Post subject:
There is code in it to unpack it.
Qndre - Sun Feb 08, 2004 3:53 am
Post subject:
Dr Brain wrote:
There is code in it to unpack it.

Oh. That's a bit Uzip-like. Uzip archives can also unpack themselves. (ZIP archives can't really. They just seem to because you see a "self-extractor" but it isn't really in the ZIP file itself but a component already installed on your system. But Uzip has the unpacker in the executable code of the ZIP file.) But if there was a code in it to unpack then RE-C may recognize it and unpack it because RE-C detects well-known algorithms and executes them before decompiling. If the algorithm is a special one for Continuum (if it hadn't existed already) then it may not be able to decompile it but it says it was written in Pascal and Pascal has a very extraordinary signature in its loop routines. It isn't very probable that the packed data contains just this signature. It might be possible but it isn't probable.
ExplodyThingy wrote:
Where exactly did you get (or think you got) ahold of the subspace source?

I attached the source code. Maybe you can check. I don't know the URL.
Quote:
You won't crack the Continuum encryption so forget about it [...]

The Continuum-encryption is 16-bit (64000 different keys). A computer can crack it within some seconds. If I used my (very inefficient) encryption cracker called "nuetzliche tools sicherheits check" then it would take two hours. But the algorithm I use is very inefficient. But there is a problem. The cracker only works with SSL-based encryptions but Continuum's one isn't SSL...
Quote:
Snrrubspace

I downloaded Snrrubspace to run it on my linux-pc but there is no executable file. What to do??
_
OK - I'll use some C-code... Then I can also use this "tick counter". But there is a problem with my C-code. I've attached it, maybe you can debug.
Smong - Sun Feb 08, 2004 8:19 am
Post subject:
~cough~ http://sourceforge.net/projects/daccel/ ~cough~

Qndre wrote:
I downloaded Snrrubspace to run it on my linux-pc but there is no executable file. What to do??
Before you ask anymore questions here, I suggest you go somewhere else and figure this out before continuing.
Cyan~Fire - Sun Feb 08, 2004 12:34 pm
Post subject:
What the hell is that code?

1) Learn C++
2) When making your test code, just make a command-line app for now.
Jason - Sun Feb 08, 2004 1:18 pm
Post subject:
Listen, Qndre, from one relatively inexperienced programmer to another, you're in way over your head here. Take the time to read up on C/C++ before you delve into this project and take a lot of time. It's painfully obvious you don't have the expertise to do what it is you want to do, and frankly, you're annoying the shit out of some of the members of this forum with your ignorant persistence.
Qndre - Sun Feb 08, 2004 2:56 pm
Post subject:
Jason wrote:
[..] with your ignorant persistence.

I am not ignorant. I just want to write the application as fast as possible, because I am really busy.
Jason - Sun Feb 08, 2004 3:38 pm
Post subject:
If you are not ignorant, stop asking for help every time you run into even the tiniest of snags and just write the damn application. It seems to me you are one of those types who is too lazy to figure things out on your own when you run into a problem, and you'd rather just come here and practically have these guys write your application for you.
ExplodyThingy - Sun Feb 08, 2004 10:37 pm
Post subject:
im not sure exactly what files you downloaded there, but you dont have subspace. It looks like an early version of Snrrrubs bot.

And yes, please please do go out and learn this material better. You really are in way over your head right now.
nintendo64 - Sun Feb 08, 2004 10:50 pm
Post subject:
ExplodyThingy wrote:
im not sure exactly what files you downloaded there, but you dont have subspace. It looks like an early version of Snrrrubs bot.

And yes, please please do go out and learn this material better. You really are in way over your head right now.


SubSpace API developed by Snrrrub.

@Qndre: Maybe Continuum is using Pascal calling convention for something, and RE-C is detecting that reference, i know SubSpace did it for zlib which is weird.

-nintendo64
Anonymous - Mon Feb 09, 2004 12:34 am
Post subject:
Hats off to you, Qndre.

I'm giving up trying to formulate a flame, simply beacuse words can't describe how retarded this thread is.
WarFan - Mon Feb 09, 2004 1:37 am
Post subject:
Dont let these guys get you down, at least your trying.

Learn it on your own or get flamed till you quit.. wow, you people are something else.
Jason - Mon Feb 09, 2004 4:29 am
Post subject:
How are we something else? He's been given tons of information to get him off the ground and yet he still hasn't gotten anywhere. He just keeps coming back here every five minutes with yet another stupid question which he could have found the answer to himself if he'd just take the time to "learn the material better" as Splody put it.

I realize these forums were put together for the sole purpose of offering help to those looking to try their hand at development and what not, but Jesus Christ... you have to draw a line somewhere as to how much help you can actually give.
WarFan - Mon Feb 09, 2004 8:38 am
Post subject:
And your point is? If you dont like seeing his posts or are annoyed by his persistance, its pretty simple, dont read them and better yet dont reply. So the guy needs help more than you or the other SS brains up in this place.. woopdifuckindoo
CypherJF - Mon Feb 09, 2004 10:01 am
Post subject:
WarFan wrote:
...woopdifuckindoo
lol

sorry for 'spam' but that was funny... i agree.. hey i give him credit for trying out new things icon_smile.gif
Anonymous - Mon Feb 09, 2004 5:01 pm
Post subject:
Ok, I'm convinced this is a joke thread now.
D1st0rt - Mon Feb 09, 2004 8:38 pm
Post subject:
I don't think it is icon_confused.gif
Grelminar - Mon Feb 09, 2004 9:57 pm
Post subject:
nintendo64 wrote:
[..]
Maybe Continuum is using Pascal calling convention for something, and RE-C is detecting that reference, i know SubSpace did it for zlib which is weird.


Isn't Pascal the standard win32 calling convention for functions imported/expored from DLLs? It's certainly what the core windows DLLs use.

Either way, I find it funny that this guy knows enough to use a decompiler on the binary, but not enough to doubt it when it claims it was written in Turbo Pascal.
Mr Ekted - Mon Feb 09, 2004 11:18 pm
Post subject:
It's written using VC++ 6.0. The reason the decompiler can't do its job is because the EXE is packed (ie encrypted).
nintendo64 - Mon Feb 09, 2004 11:34 pm
Post subject:
Grelminar wrote:
[..]



Isn't Pascal the standard win32 calling convention for functions imported/expored from DLLs? It's certainly what the core windows DLLs use.


I believe the standards are stdcall and safecall, well the major difference between Pascal convention and others (except for register convention) if that it passes parameters from left to right, maybe RE-C is detecting that in Continuum.

After what Qndre said i used the Decompiler on the unpacked version and it gave me some Pascal references, too. Althought not much just 3, well i haven't gone deeper into that matter anyway, not that i care much about it icon_smile.gif.

-nintendo64
Grelminar - Tue Feb 10, 2004 2:09 am
Post subject:
Um, stdcall is a synonym for pascal calling convention. The argument order is kind of important, but the decompiler would have no way of detecting that. The more important difference is that the callee pops the arguments from the stack instead of the caller, which is easy to detect.
Mr Ekted - Tue Feb 10, 2004 2:19 am
Post subject:
Compilers that heavily optimize may make it very tough to decompile, like:

push a
push b
push c
call func1
push d
push e
call func2

The statement "push a" could be the first argument of func2.
nintendo64 - Tue Feb 10, 2004 12:36 pm
Post subject:
Actually, stdcall is much of like an hybrid between Pascal and C Convention. It passes parameters from right to left. Also Pascal convention is mostly for backward compatiblity as it was made for Win16 apps, of course you could say stdcall and Pascal convetion are the same, but they have obvious differences.

What i mean about a calling convention afecting what the decompiler displayed. It's because the C convention in asm code pushes the parametes from the right to the left while a Pascal convention will do the reverse operation, since the Decompiler it's pretty much reading ASM code, maybe it'll display this.

-nintendo64
Grelminar - Tue Feb 10, 2004 7:43 pm
Post subject:
My point was that a decompiler can't possibly tell the difference between right-to-left and left-to-right, because that depends on the order that they were declared in the source code, and the source code isn't around anymore. What it can tell, and very easily, is whether it's the caller or callee that fixes the stack pointer after the call.
Qndre - Wed Feb 11, 2004 2:45 pm
Post subject:
Quote:

It seems to me you are one of those types who is too lazy to figure things out on your own when you run into a problem, and you'd rather just come here and practically have these guys write your application for you.

That's not right. I've written many applications without anyone's help at example even a very simple GUI for DOS so you can use 256 colors and 640x480 instead of just 16 colors. (no, it's not very powerful, it was just a test application but it was more powerful than W3.1 *laugh*).

I also started trying a full 3D game but I stopped with that because the self-written graphics renderer wasn't good. And I've written several office-like programmes for calculating spreadsheets or editing text or multimedia content and some encryption-, password-protecting- and compression-algorithms. And I've written a webserver which I now want to combine with this Continuum-like client (you know the story).

The server is called "SpecServ 2.0" (yes it's the second version, the first didn't work and I deleted it to re-write it right from the start). There are some problems with the implementation of the HTTP protocol (the browser can transfer data to the server but not the other way), but these problems will be easy to solve because there is much information on the internet. This spec-client was the only program I needed help for. That's because it's based on existing software. (Like the subgame2 server is) and I don't know much about this existing software (Yes I could easily write a Continuum-like software, I've written some multiplayer games, yet. If the server was also invented by me then it won't be too much of a problem. But I want to write a client for the existing subgame2 server.)

And I've even written an "unencrypter" or crack for the MD5 encryption but that software isn't useful because MD5-encryption takes thousands of years to deincrypt (if you only have 2 bytes then it doesn't take very long but if you encrypt a whole application into a MD5-hash then it takes thousands of years). If MD5 used the last of all keys (and the software tried every other key before then it would take between 30,000,000,000,000 and 800,000,000,000,000,000,000,000,000,000 years (depending on your computer speed).

So you see some applications aren't useful but I wanted to show someone who thought he was very very experienced that he was not right as he said: "It is impossible to decrypt a MD5 hash, it wouldn't take a long time it's simply impossible because the key is dynamic.", and I told him: "If you try every possible key then you will get the data which was encrypted by MD5 algorithm." He said I was stupid but I said to him "encrypt 2 bytes into an MD5 hash and I will give you your 2 bytes unencrypted within 50 seconds". He did and now he knows that I am able to do that.
Jason - Wed Feb 11, 2004 4:26 pm
Post subject:
Holy run on sentences, Batman!

Qndre, I apologize for being overly harsh to you earlier. I was most likely just in a pissy mood. Keep working at this project. I'm interested in seeing how it turns out.
Mr Ekted - Wed Feb 11, 2004 5:38 pm
Post subject:
Qndre wrote:
And I've even written an "unencrypter" or crack for the MD5 encryption but that software isn't useful because MD5-encryption takes thousands of years to deincrypt (if you only have 2 bytes then it doesn't take very long but if you encrypt a whole application into a MD5-hash then it takes thousands of years). If MD5 used the last of all keys (and the software tried every other key before then it would take between 30,000,000,000,000 and 800,000,000,000,000,000,000,000,000,000 years (depending on your computer speed). So you see some applications aren't useful but I wanted to show someone who thought he was very very experienced that he was not right as he said: "It is impossible to decrypt a MD5 hash, it wouldn't take a long time it's simply impossible because the key is dynamic.", and I told him: "If you try every possible key then you will get the data which was encrypted by MD5 algorithm." He said I was stupid but I said to him "encrypt 2 bytes into an MD5 hash and I will give you your 2 bytes unencrypted within 50 seconds". He did and now he knows that I am able to do that.


That is the most painfully stupid thing I have ever read.
Mine GO BOOM - Wed Feb 11, 2004 6:16 pm
Post subject:
I've added some paragraphs into the above post from Qndre, so people could/would read it.

You know, since Ekted is posting in here, he could always add your suggestion into the client if he was so inclined to do so.

As for your MD5 decryptor: HAHAHAHAHAHA.

*ahem* Sorry, I really shouldn't have done that. But anyways, programs cannot be "encrypted" into an MD5 checksum. Thats why it is called a checksum. If you work out the math, there are infinite strings of bytes that could go through the MD5 checksum method, and reach any checksum.

Practically speaking, if you knew the length of the information before hand (such as your 2 bytes one), you could try everything of that length. Now, assuming MD5 checksums are perfect (every single 16 byte string has a unique checksum), which they are not, then once you reached a string of bytes longer than 16, there could be more than one match for every checksum, of the same length.

Why? Because of the laws of compression. You cannot compress a complete sample space, containing only unique items, into anything smaller. The actual theory/law that states this, I cannot remember. Check with a math professor.

Theoretically speaking, if you took the checksum of Continuum, and you set your program thing loose on it, there would be at some point, at some unknown length (but probably insanely large, like one billion raised to the one billionth power), you would come up with a program that would be identical, in function, to Continuum, but instead, would have the name "Bob".

If you don't understand this, just think of it this simple model.
Checksum = INPUT % 16
Have an input of 10, you get 10.
Have an input of 58, you get 10.

All checksums have this flaw. Just some require a lot bigger range before the flaw shows.
Mr Ekted - Wed Feb 11, 2004 6:19 pm
Post subject:
MGB just laughed at you. Do you feel stupid yet? icon_smile.gif
Cyan~Fire - Wed Feb 11, 2004 8:30 pm
Post subject:
MGB wrote:
You know, since Ekted is posting in here, he could always add your suggestion into the client if he was so inclined to do so.

You know, since Ekted is posting in here, you should probably stfu about cracking Continuum encryption, Qndre. icon_razz.gif

About your other programs you wrote, such as a webserver, a graphics-rendering engine, and Qndre Office for Dos 6.0; did you write all of these in BASIC? I haven't heard you refer to another language and your C++ code was so ludicrous I can't imagine you've actually ever used a language that's been written in the past decade.

I'm not trying to be mean or flame-ish, but you seem to think that the world's programming standards and security are a joke. They really are not. MD5 checksumming is genious. The most serious crackers have problems with it, and I can't bring myself to believe that you, a BASIC programmer, have written a program that will flawlessly 'crack' the checksumming process. (Since you don't actually seem to understand what MD5 does, I find it doubtful you've written the program anyway.)
Mine GO BOOM - Wed Feb 11, 2004 9:00 pm
Post subject:
Cyan~Fire wrote:
You know, since Ekted is posting in here, you should probably stfu about cracking Continuum encryption, Qndre.

There is nothing wrong with him trying to do this via reverse engineering. In fact, if he does that, I'd congradulate him for it. But the fact that he is having problems with a decompiler, and believes Continuum was done in Pascal, shows that he won't be able to. But no harm in trying..

And in the rare chance he does this, maybe Priit would change a few lines around, and finally release 0.39.
Mr Ekted - Wed Feb 11, 2004 9:23 pm
Post subject:
Hmm, 2 encrypted bytes....writes code....compiles....waits 27 nanoseconds....

Is it perhaps one of these 65536 values? Yay!

</joking>
Cyan~Fire - Thu Feb 12, 2004 4:53 pm
Post subject:
The thing I was saying was that since Ekted's here (Hi Ekted!), he could very easily get the encryption changed if it was discovered.
Mr Ekted - Thu Feb 12, 2004 8:57 pm
Post subject:
Good programmers are naturally curious. They will figure things out as a challenge, no matter what their motivation. On its own, this is a good thing. When people come to me who want to make their own bot system, I would just help superficially, letting them get more deeply into it. When they reached a certain level of understanding, I would help them more freely. I guess it's like Deep Throat's role in the Watergate story. icon_smile.gif

SS is generally safe no matter what people do. The worse thing that could happen is someone cracks Cont encryption, makes some very subtle cheats, and keeps it completely to himself and a small group of friends. This is mitigated by several things: Can they ALL really resist the urge to brag? Will the cheats be so subtle they don't make any difference anyways? If it did get out, it could be addressed virtually overnight. It's really just a big game of leapfrog, where Cont can change in a day, and a new crack would takes months.
ExplodyThingy - Thu Feb 12, 2004 9:34 pm
Post subject:
Are you saying that the really gifted dont have enough self control? Motivated by /. ( http://slashdot.org/articles/04/02/12/2114228.shtml ), if I were to ever attain access to the encryption, any part of the source, any capacity to cheat, or safely and undetectedly cheat, I would make it either a) Look like I did it apart from anything that needs patching or b) do it right, and keep it limited.
Mine GO BOOM - Thu Feb 12, 2004 10:17 pm
Post subject:
Arg, /. links on my forums, so ugly. Well, in light of that, I think Continuum's source needs to be leaked..
Code: Show/Hide
... decryptPacket ...

I did my part, now you guys can fill in the dots.
Mr Ekted - Thu Feb 12, 2004 10:29 pm
Post subject:
ExplodyThingy wrote:
Are you saying that the really gifted dont have enough self control?


No, just that it's tough not to tell someone when you've just spent a month working 24/7 on a challenge like that.
Qndre - Sat Feb 14, 2004 10:33 am
Post subject:
Cyan~Fire wrote:

you don't actually seem to understand what MD5 does

Yes I understand. It takes every single byte and makes a 16-bit value out of the (8-bit) byte. Then it rotates the first byte one bit to the left and the second byte two bits to the left and the third byte three bits to the left. The 16th byte isn't rotated to the left and the 17th byte is rotated one byte to the left and so on. Then all (rotated) bytes of the input data are combined using XOR operation and finally a constand is added using XOR operation (I don't know any more if the number of bytes in the input string is added using XOR opetation but the constant is "d41d8cd98f00b204e9800998ecf8427e"). MD5 is called MD5 because it does it 5 times with 5 different keys so you get a 128-bit hash even if it is only a 16-bit value but different ones of the 5 encryption cycles with a 128-bit key. I've also created an MD5-like hash function which does nearly the same but it only works with a 16-bit fingerprint and a 64-bit key (I know that's not secure) so the 16-bit-value is combined with different keys so that you get 64-bit at the end. And I've got the sourcecode of MD5: http://www.qndretreff.de/sourcecode/md5.txt and of SHA1: http://www.qndretreff.de/sourcecode/sha1.txt
Quote:
If you work out the math, there are infinite strings of bytes that could go through the MD5 checksum method, and reach any checksum.
Yes I know even if all the people I know say "that's not right - every MD5 is unique". But I know that it can't be true because a 128-bit value can't take more than 3.402823669+E38 values. And that's why I know that Continuum encryption can't be too difficult to crack. It's a 16-bit-key and a 16-bit-value can't take more than 65536 (yes the magic computer number) different values. And that's not very much.
Mine GO BOOM - Sat Feb 14, 2004 12:11 pm
Post subject:
Qndre wrote:
"that's not right - every MD5 is unique"


No, what I said is that it can reach any checksum you want. So if you want the checksum containing all 0's, there are infinite number of inputs that can create that checksum. So, thats the opposite of unique.

As for the 16bit key, you may want to sniff the packets a bit better. It isn't 16bits.

Also, why would an encryption be based upon a checksum? Checksums are designed to check data, to make sure it is the correct information. Thats why there is a simple XOR, one byte checksum inside ship position packets, so people couldn't just "oops, no more weapon data" inside them, or edit their outgoing packets and add weapon data to them, or change all bullets to bombs. As soon as they tried that, without knowing that there was a checksum inside the data, the server would trigger a sysop warning, and they'd be banned very shortly before they figured out that there was a checksum inside the packet. So, back before Jeff added encryption protection, thats what this was for.

Encryption is only designed so its hard to figure out whats in the packet, and by doing so, makes it very hard to edit the data inside. Also, encryption methods cannot be lossy, as the point behind them is at sometime, someone will have to decrypt it and get the original information back. As all checksums are lossy (they override data during their calculation), checksums cannot be used for encryption.

As it is obvious that you are new to programming, you should know that decompiling a program is illegal to do in the business world. Blackbox reverse engineering, which is how everyone figured out how the packet protocol, is perfectly fine, as long as you are not tinkering with the memory of the program while doing so.

Whats the difference? Reverse engineering only ties the input to the wanted output, in a way you create. So, its new, and you personally figured it out, thus it is your intellectual property (IP). Decompiling and figuring it out that way steals someone elses IP, and thus is protected under the law. If you happened to notice that thing you agreed to everytime Continuum is released with a new version, you'd notice that you do not own the IP, and thus, cannot use it without his permission.

Even though it says reverse engineering isn't allowed, it has been held up in the courts with other projects that it is acceptable. Decompiling has been held up in the courts as very illegal, with pretty hefty fines.

Quote:
The following End User Licence Agreement (hereon referred to as LICENCE) defines terms and conditions of play when using this software/this product as well as the legal relationship between the user of this software and any participant in this online game network, and providers of this software and the operators of various services that maintain the online network. Failure to comply with the terms and conditions listed below can result in the revokation of this LICENCE and loss of the ability to play this game on a given network.

You must read this Product LICENCE carefully. By pressing Accept and using this software, you are agreeing to abide and be bound by the terms and conditions of this LICENCE and are acknowledging that you have read and understand said terms. If you do not agree to the terms of this LICENCE, please click Decline and immediately remove this software from your computer.

1. GRANT OF LIMITED LICENCE. You, the end user, are hereby granted a limited licence to make use of this product for your personal enjoyment on any type or number of computers or game platforms to play on a game network. This LICENCE is transferable, and you may freely distribute this product as long as all files from the original distribution are included, unchanged and unmodified, including this LICENCE. This LICENCE is proof of your right to exercise the rights and privleges stated within. Any other use of this software for purposes not stated may result in termination of this LICENCE.

2. COPYRIGHT. You have no ownership rights in regards to this software product. All works contained herein are copyright and property of their respective owners and are protected by United States copyright laws and international treaties and provisions. You are not granted any rights other than those expressly stated within this LICENCE. This software should be treated like any other copyrighted material, with the express exception that it may be freely copied and distributed within the guidelines listed in Section 1.

This software is licenced to you only for your personal enjoyment and the enjoyment of others. It is provided free of charge and may not be used for any commercial purposes whatsoever. You may not loan, rent, lease, sell, give, offer for sale, sublicence, or othwerwise transfer this product, or any portion therein, or any portion incorporated therein (such as visuals or sounds) in exchange for any monies, revenue, or other services. You may not permit someone to use this software in exchange for anything, this software should be distributed free of charge or commitment.

You may not recreate, modify, adapt, translate, create derivative works of, decompile, disassemble or otherwise reverse engineer or attempt to reverse engineer or derive source code from, all or any portion of this product or anything incorporated therein, including any screen display, sound or accompanying documentation, or permit or encourage any third party to do so.

3. COMMERCIAL EXPLOITATION PROHIBITED. Without limiting the generality of the foregoing restrictions, specifically you may not offer this product on a pay-per-play basis or on a subscription basis or on a computer system or network to which you lease or rent access to players.

4. GAME SERVERS. The only authorized method of accessing any server to use the Product is by using an unmodified copy of this software as originally distributed. You shall select and then use any such server all at your sole cost, expense and risk, including any communication costs, such as telephone charges and/or Internet access fees.

No one shall retain responsibility or liability to you or any other person or entity for selecting a server, any technical, service or other problems or difficulties that you may experience in connection with connecting to or using a server, any player’s compliance with any rules or procedures set forth in this LICENCE, the acts or omissions of any player or any cost or expense incurred by you in connection with the selection, use, or otherwise in connection with any server. No guarantee is made that the software used by server operators is the original, unmodified server software. Servers are generally privately owned and operated and no guarantee is made that you will be able to access all servers: different servers may have different accessibility rules.

5. APPROPRIATE GAME PLAY; RESPONSIBILITY FOR GAME PLAY. You agree to not take any action or pass any communication, either in or through this product or in or through any other software, that interferes with another player’s ability to enjoy his or her play of the game or which is objectionable or inappropriate. Your conduct in the game may affect your ability to play on a given server. Rules of conduct are left to the discretion of each server operator. Without limiting the generality of the foregoing, the definition of objectionable and/or inappropriate actions includes intentionally or unintentionally violating any applicable local, state, national or international law, regulation or treaty. You are completely and solely liable for all communications and other activities of every kind and nature conducted by or through your screen name/log-in name.

6. LOSS OF PRIVILEGES. In the event that you engage in conduct prohibited by this LICENCE, or otherwise commit any other breach of this LICENCE, then one or more of the following may occur: you may be issued a warning; your account’s chat or other communication abilities may be turned off; use of your account may be temporarily or permanently blocked; and your use of any other on-line gaming or other similar account that you then or may in the future maintain with the operator of the server or their respective affiliates may be temporarily or permanently blocked.

7. NO MONITORING OR PRIVACY. Communications in connection with this software are not private and often occur in real-time. Although the rules regarding appropriate game play are set forth in this LICENCE, there is no guarantee that any person or entity will, as a matter of policy, screen, edit, monitor or police the content of the communications or other materials transmitted by players, and therefore there is no promise or guarantee that other players will not provide content or access to content that players or their parents may find objectionable or inappropriate. Notwithstanding the guarantee of any policy of screening, editing, monitoring or policing the content of the materials or communications transmitted by players, you acknowledge and agree that, to the extent permitted by applicable law, the operator of the server may, in its sole discretion, monitor some, all or none of the "chat" and other areas of the game for adherence to this LICENCE, choose to act upon inappropriate use of "chat" features or game play, collect, disclose, distribute, compile and otherwise use for its purposes, as it deems appropriate, any and all data and information gathered from use of this software and its "chat" features. Servers operating with the official unmodified server software are incapable of monitoring "private chat," but no guarantee is made that all server are using the official unmodified server software.

8. LIMITED WARRANTY. You expressly acknowledge and agree that use of this software is at your sole risk. This product is provided "as is" and without warranty of any kind.

9. NO OTHER WARRANTIES. ALL OTHER WARRANTIES, EXPRESS, IMPLIED OR, TO THE EXTENT PERMISSIBLE BY LAW, STATUTORY, INCLUDING ALL WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, WITH RESPECT TO THIS PRODUCT ARE DISCLAIMED. NO WARRANT IS GIVEN THAT THE PRODUCT WILL SATISFY THE REQUIREMENTS OF YOUR COMPUTER SYSTEM OR THAT THIS SOFTWARE IS WITHOUT DEFECT OR ERROR OR THAT THE OPERATION OF THE PRODUCT WILL BE UNINTERRUPTED.

10. USER REMEDIES. No express user remedies will be provided. This software is provided free of charge and is provided "as is."

11. LIMITATION OF LIABILITY. IN NO EVENT SHALL ANYONE BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, CONSEQUENTIAL, SPECIAL, INDIRECT, DIRECT, INCIDENTAL, LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OR INABILITY TO USE THIS SOFTWARE, EVEN IF IT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES AND/OR JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. SINCE THIS SOFTWARE IS PROVIDED FREE OF CHRAGE, IN NO EVENT SHALL ANYONE'S LIABILITY BY OPERATION OF LAW, IF ANY, BE GREATER THAN ZERO. THE WARRANTY AND REMEDIES SET FORTH HEREIN ARE EXCLUSIVE AND IN LIEU OF ALL OTHERS, ORAL OR WRITTEN, STATUTORY, EXPRESS OR IMPLIED. NO DEALER, DISTRIBUTOR, AGENT OR EMPLOYEE IS AUTHORIZED TO MAKE ANY MODIFICATION OR ADDITION TO THIS WARRANTY.

12. GENERAL. This LICENCE sets forth the entire agreement between the parties with respect to the subject matter hereof and supersedes all prior negotiations, understandings and agreements, whether written or oral, between the parties hereto concerning the subject matter hereof. This LICENCE is severable. Should any provision of this LICENCE be held to be void, invalid or unenforceable, the remaining provisions hereof shall not be affected and shall continue in effect as though such unenforceable provision has been deleted herefrom. The name of this LICENCE and the headings of the sections of this LICENCE are inserted merely for convenience and shall not be used or relied upon in connection with the construction or interpretation of this LICENCE.

IF YOU AGREE WITH ALL OF THE FOREGOING TERMS AND CONDITIONS, THEN PLEASE CLICK THE "ACCEPT LICENSE" BUTTON. OTHERWISE, CLICK THE "DO NOT ACCEPT" BUTTON BELOW AND PROMPTLY REMOVE THIS SOFTWARE FROM YOUR COMPUTER.

Qndre - Sat Feb 14, 2004 1:15 pm
Post subject:
Mine GO BOOM wrote:

you should know that decompiling a program is illegal to do in the business world

If I write my software then it should be legal because of four reasons:


1. The Continuum server is a free software. You do not have to pay for it everyone can get it for free. Even the source code is available.

2. If I do not use the original source code but write a completely different one and only use the reverse-engineered source to figure it out then I don't "steal" the source code.

3. I don't want to publish my software. It's for private use only.

4. I only want to write a new client for an existing data protocol. That is NOT illegal. You can also write a web browser without having a kind of "license" for the HTTP-protocol. Or you can write game servers for example for HalfLife (there are many of them) and it's legal. And Snrrub did also write a client for Subspace. That was not illegal. My chat-friend wrote a Continuum client (not Subspace but full Continuum client) that creates a radar-view of the map and sends it to other PCs on the LAN. And it wasn't against the law.

5. PriitK also isn't the real "owner" of Subspace. He has re-written the client. The real "owner" of the Subspace client was VIE. And PriitK was allowed to do. So why shouldn't I do?
ExplodyThingy - Sat Feb 14, 2004 1:36 pm
Post subject:
You have a LOT of misconecptions. I suggest stop posting n this for a while, and work on it. See what you can come up with and see what happens. Tinker and toy some more.
Mine GO BOOM - Sat Feb 14, 2004 1:47 pm
Post subject:
  1. The Continuum server? I'm assuming you mean ASSS. The protocol is pretty well know, by reverse engineering. The VIE encryption is illegal, as someone ripped the code from the old binaries, and then someone converted that into human-readable form, in which was then coded to whatever language you want.
  2. There is no such thing as "reverse-engineered source", because if you use a decompiler to get that source code, you didn't reverse engineer it. Also, its illegal to "look" at someone else's source code, and use that to write your own. If the coders of WINE looked, or glanced, at the leaked Windows source code, that project would die instantly. Microsoft would be all over their ass. In fact, that project and others are in danger because if someone submits some code now in the future, they are in danger that that user figured that part out via browsing the Windows source.
  3. Private or public, its still illegal. Just the part of getting caught is different. If you rip music and give it to your friends, thats illegal, but very private. If you rip music and give it to everyone, everywhere, such as on your own free-music.com site, thats illegal, and public. The only difference between the two is which is more likely to be caught.
  4. Writing for a known protocol that is open, such as HTTP, is perfectly fine. As for that Continuum Client, I think you are getting Continuum and Subspace mixed up. Continuum is just a new client software, which was cloned by viewing input/output only, for Subspace. Subspace itself can be refered to as the old client software written by VIE, or the protocol (which is what Continuum still uses), or the server software (subgame.exe). The only functional difference between Continuum and the VIE client for a server is which encryption method is used. So if your friend made a "Continuum client", that means he used Continuum's encryption, and thus the server thinks it is a Continuum client, and not VIE.

    So in the future, please refer to these new clients via encryption methods used for communication, as that is the only functional difference in their communcation with the server.

The legality part is only in reference to what you may do in the future. Continuum may in itself be illegal, but the owners of the Subspace client know we exist, and as long as we don't ever make a cent off it, they don't care (this is actually in the license agreement above). But if you ever do this for any project in the future, in which would be sold for money, you really need to know the difference of this. "Looking" at someone else's code, in which you do not have the license to do so, and using that to make your own code is illegal.

Do this for Continuum would never get you in trouble. But it is good to know what will if you ever make a product in which has an income.

Its against the law to speed, but everyone does it. The real reminder of this is when you get caught.
Qndre - Sat Feb 14, 2004 2:05 pm
Post subject:
Mine GO BOOM wrote:

The Continuum server? I'm assuming you mean ASSS.

No. I mean Subgame2.
Mine GO BOOM wrote:

as long as we don't ever make a cent off it, they don't care

I also don't want to earn money with my program. I only want to have a new challange. I want to show the people that it's possible. I want to know where my experience in program development is over. Maybe I know what I am able to do. But I don't know what I am not able to do. Maybe I can check it out with this project. And maybe I can make myself able to do it even if I haven't been able to do it before. I also don't really believe that I'm able do it but I want to do it. There is a little difference. biggrin.gif
Nintendo64 wrote:

Continuum encryption has been cracked in the past

Mr Ekted - Sat Feb 14, 2004 5:17 pm
Post subject:
We do not have sources for subgame.

If you look at ASM for a program, and use that info to make your own program, it is essentially illegal.

PriitK was not "allowed" to make Cont. It's just that no one complained.

Your friend did not make a full Continuum client.
Cyan~Fire - Sat Feb 14, 2004 5:27 pm
Post subject:
Qndre wrote:
No. I mean Subgame2.

The subgame2 source code is not available.

And yes, Continuum encryption may have been cracked in the past, but I made a comment earlier about cracking it. If you crack the code, a new version will come out with a different code. It's that simple. And since Ekted is surfing around here (as I also said earlier), Priit would very likely find out about your crack immediately.
CypherJF - Sat Feb 14, 2004 5:34 pm
Post subject:
*sits back and watches the debate continue*
ExplodyThingy - Sat Feb 14, 2004 6:41 pm
Post subject:
*giggles uncontrollably*
nintendo64 - Sat Feb 14, 2004 9:00 pm
Post subject:
nintendo64 wrote:
I will say this much, Continuum encryption has been cracked in the past (versions 0.35, 0.36 and 0.37)...


I specified which versions, that i know of been cracked, but i am only certain for version 0.36 (i saw the application which contained the encr), of course that was a long time ago and the people that did it, are not interested in Continuum anymore. Well it doesn't matter, because if someone cracks it for purposes that will disrupt gameplay, PriitK will just patch it.

Mr Ekted wrote:
Your friend did not make a full Continuum client.


What do you mean by friend Mr Ekted? if you mean me, because he quoted me. You better don't assume anything icon_smile.gif. Oh and i am not his friend. Just someone that likes to help from time to time.

-nintendo64
D1st0rt - Sun Feb 15, 2004 12:13 am
Post subject:
he was referring to the one Qndre said wrote a full continuum client
nintendo64 - Sun Feb 15, 2004 2:32 am
Post subject:
D1st0rt wrote:
he was referring to the one Qndre said wrote a full continuum client


Oh, i just read the line he said his Chat-friend made some client... Well i mostly just glance at his replies (if they lack numbers), because they are rather...... not interesting.

Oh well, my bad, sorry, i will just throw the famous excuse of foreigners icon_smile.gif, english is not my first language biggrin.gif.

-nintendo64
Qndre - Sun Feb 15, 2004 9:47 am
Post subject:
Mr Ekted wrote:

[..]
PriitK was not "allowed" to make Cont. It's just that no one complained.
[..]
Your friend did not make a full Continuum client.

I don't know. He just told me. I asked him if I could see it then he went offline. *strange* biggrin.gif
Next time he went online I asked if it was a Continuum client or just a Subspace client and he said a Continuum client. I asked him about the compatiblity and he said C36 and upwards (C37, C38, C39, C40, C41,...). I told him that C40 and C41 aren't out yet and he said "I know but I can fake all signatures you want!".
And you said that PriitK wasn't allowed to write a new client but no one complained. He can't complain about it because it is NOT HIS WORK! It's VIE's work. He just re-wrote it. And even if he was the owner of the Copyright then he can't complian because I don't use instances of his software. I only use his data protocol. If you write a web-browser and you have no "license" for the HTTP-protocol then it's also not illegal.
Quote:

Writing for a known protocol that is open, such as HTTP, is perfectly fine. As for that Continuum Client, I think you are getting Continuum and Subspace mixed up. Continuum is just a new client software, which was cloned by viewing input/output only, for Subspace. Subspace itself can be refered to as the old client software written by VIE, or the protocol (which is what Continuum still uses), or the server software (subgame.exe). The only functional difference between Continuum and the VIE client for a server is which encryption method is used.

It doesn't matter if I write a Continuum or a Subspace client. It's nearly the same. You told me that I need Continuum to recieve LVZ so I'll need to write a Continuum client. If there is another possibility to get the LVZ from the server by emulating a Subspace client then I'll write a Subspace client.
_
But it can't be illegal to look at the source of Subspace because it is OPEN SOURCE!!!!
Qndre - Sun Feb 15, 2004 10:24 am
Post subject:
Can't find the website of VIE. Already searched Google for it.
But a DSB op helped me.
Code: Show/Hide

   Qndre> ?help is subspace's network protocol copyrighted?
          Message has been sent to online moderators
Op>Super> dont know
   Qndre> i don't believe but someone told me
   Qndre> because i wanted to write a new client
Op>Super> dont see how they can stop u if its free
   Qndre> it's not only free - it's open-source
   Qndre> thx for your help
   Qndre> bye

Quote:

The subgame2 source code is not available.

Oh - why do I have it then?
ExplodyThingy - Sun Feb 15, 2004 11:25 am
Post subject:
You dont. I assure you. The protocol (or the game at least, which includes the protocol) is definately copyrighted. Because there is no profit whatsoever, no one really cares. VIE has no website because there is no VIE anymore. Thats how (and why) PriitK made continuum. Continuum is not an enhancment of subspace. Continuum is what youre trying to do, a whole new client.
Qndre - Sun Feb 15, 2004 11:29 am
Post subject:
ExplodyThingy wrote:
VIE has no website because there is no VIE anymore. Thats how (and why) PriitK made continuum. Continuum is not an enhancment of subspace. Continuum is what youre trying to do, a whole new client.

But VIE = Verign Interactive Entertainment. And Verign is a company which writes computer games. And it exists because even the famous game Descent is made by Verign. I know that Continuum is not an enhancement of subspace but it is 99.9% Subspace compatible.
nintendo64 - Sun Feb 15, 2004 12:19 pm
Post subject:
Qndre wrote:
[..]


But VIE = Verign Interactive Entertainment. And Verign is a company which writes computer games. And it exists because even the famous game Descent is made by Verign. I know that Continuum is not an enhancement of subspace but it is 99.9% Subspace compatible.


Qndre gets your facts straight before you start defending yourself with them... Virgin Interactive Entertainment (Not Verign) was divided in two branches at that time VIE-US and VIE-UK(which still exists). VIE-US made SubSpace and it was the same which went bankruptcy.

On a side note VIE-UK is now Avalon Interactive.

http://www.vie.co.uk/

About your friend: if he indeed made a clone of Continuum why doesn't he tell you how CTM encryption works or send you the whole source code, so you will just rip what you need.

Qndre wrote:
[..]
it can't be illegal to look at the source of Subspace because it is OPEN SOURCE!!!!


When did BDE (Oznaq2 branch) release the source of SubSpace? As far as i know they haven't. The SubSpace source code is far from being OPEN SOURCE. Bots exists because someone ripped the SubSpace encryption, security checksums, position packet checksums and figured out what most packets did. Continuum exists because PriitK has been working on Bots before everyone started so he figured out most of the packets or all.

-nintendo64
ExplodyThingy - Sun Feb 15, 2004 12:19 pm
Post subject:
Its 100% subspace compatible becuase he wrote it very well.

VIE went under a couple of years ago.
Cyan~Fire - Sun Feb 15, 2004 1:19 pm
Post subject:
Lol I get the feeling you're pulling "facts" out of your @$$, Qndre.
CypherJF - Sun Feb 15, 2004 2:05 pm
Post subject:
To my knowledge none of the Subspace/Server software has become open-source. It's closed-source for several reasons, discussed here:

http://www.ssforum.net/index.php?showtopic=84&st=0

Starting a few responces down, for the next few pages....
Qndre - Sun Feb 15, 2004 2:16 pm
Post subject:
CypherJF wrote:
To my knowledge none of the Subspace/Server software has become open-source. It's closed-source for several reasons, discussed here:

http://www.ssforum.net/index.php?showtopic=84&st=0

Starting a few responces down, for the next few pages....

It's open-source because Snrrrubspace is open source and Snrrrubspace is equal to Subspace. I've already seen the Subgame2 (Server) source. It wasn't the original source but an implementation of the Subgame2 (69.000 lines in C-code). The site went offline because the owner wasn't sure if he was allowed to publish the source. Because he didn't want to get in trouble he set his site offline.
_
About Continuum encryption which
Quote:
none of us has cracked it yet

It's a very very very very very very simple encryption.
Mine GO BOOM - Sun Feb 15, 2004 3:38 pm
Post subject:
Qndre wrote:
It's open-source because Snrrrubspace is open source and Snrrrubspace is equal to Subspace.

Snrrrubspace is a new client, like Continuum. The only difference, is the maker of one client also hacked the server software to support a new encryption, and the maker of the other client got it to work a bit. Please, learn the difference between clients, protocols, and server names.


Qndre wrote:
About Continuum encryption which
Quote:
none of us has cracked it yet
It's a very very very very very very simple encryption.

Good, tell me ONE bit of information you know about the encryption of Continuum. Just ONE bit you know for a fact.
nintendo64 - Sun Feb 15, 2004 4:18 pm
Post subject:
Qndre wrote:
It's open-source because Snrrrubspace is open source and Snrrrubspace is equal to Subspace. I've already seen the Subgame2 (Server) source. It wasn't the original source but an implementation of the Subgame2 (69.000 lines in C-code). The site went offline because the owner wasn't sure if he was allowed to publish the source. Because he didn't want to get in trouble he set his site offline.


So basicly because OpenOffice opens up files with *.doc extension, it means Microsoft Office is open source too?

Qndre wrote:
It's a very very very very very very simple encryption.


You know is very very very very very very simple for someone to come here and said It's 16bit key encryption a PC can crack it easily trying all the possible keys and continue on and on about how easy is to crack the encryption, and even mention tons of other encryption methods he supposedly knows how to crack, and YET HE HAS NOT CRACKED THE CTM ENCRYPTION.

C'mon Qndre, bring us some proof about how this encryption is so damn easy to crack, C'mon Qndre, you didn't even know Continuum was packed, and lots of us knew that (doesn't takes a genius to know it).

-nintendo64
Jason - Sun Feb 15, 2004 4:40 pm
Post subject:
Dear Qndre,



Love,

~J
Mr Ekted - Sun Feb 15, 2004 7:39 pm
Post subject:
Qndre, you are a very confused person.

1. The source code to Subspace.exe and Subgame2.exe are not published anywhere. The source that you have seen is stuff other people have made to try to re-create those applications. Snrrrubspace is a client designed from scratch. ASSS is a server that was designed from scratch. The new billers out there were designed from scratch.

2. The Continuum encryption is not known. And it is not a very very very simple thing.

You came here looking for help, but all you do is talk out your ass.
Mine GO BOOM - Sun Feb 15, 2004 7:54 pm
Post subject:
Dear Jason,

"The owner of this file has exceeded their daily usage limit." Try the Attachment button on the forums.

Love,

~M
CypherJF - Sun Feb 15, 2004 8:06 pm
Post subject:
rotfl icon_smile.gif feelin the love around here XD
Jason - Sun Feb 15, 2004 9:11 pm
Post subject:
The pic is showing up just fine for me. Meh, it's just VillagePhotos. It's attached now anyway.
Mr Ekted - Sun Feb 15, 2004 9:22 pm
Post subject:
It's probably in your cache.
CypherJF - Sun Feb 15, 2004 9:54 pm
Post subject:
LOL nice one jason rotfl
Jason - Sun Feb 15, 2004 10:10 pm
Post subject:
You're correct, Ekted. It sure was. :]
ExplodyThingy - Sun Feb 15, 2004 10:46 pm
Post subject:
Yeash...

Qndre - Mon Feb 16, 2004 7:51 am
Post subject:
It seems to me like you didn't understand what I mean or I didn't understand what you mean. So I'll try to explain my point of view.

Quote:
ASSS - Open source, from scratch, server software in which Grelminar did.
I didn't know it exists some weeks ago.

Nintendo64 wrote:
So basicly because OpenOffice opens up files with *.doc extension, it means Microsoft Office is open source too?

No I didn't say anything like that but if you have the source of OpenOffice you can write an application which can also open *.doc files. That's what I said. I don't want to clone Continuum. I didn't say Continuum was open-source. I said that I've already seen the source of other Subspace Clients but I see in this thread there are many misunderstandings. I want to write a full new client for it and if you are right and if it is not possible to do it then I'll write it for the old VIE encryption. I'll first try to crack the Subspace encryption. And if my Client can log on to a Subspace server and spectate and log off again then I can TRY to implement the new encryption for CTM too. I am NOT sure if I can do it. But it seems to me like it's a very simple algorithm. I don't really know if it's as simple as I think but it SEEMS TO BE very simple. There's a little difference. I'll send some bytes through the algorithm maybe I can check out how it works.

Mr Ekted wrote:
Qndre, you are a very confused person. [..]

No I am not. I trust in the information other people (who say they are experienced) give to me that's all. I haven't tried out so much with the Subgame2 server and it seems like I am not as experienced as you are. But you don't have to shoot my little knowledge down even if you know more than I do. I don't know much about it. If I would then I wouldn't have come here. Another person (who said he had worked on a Continuum client) gave me the information about the CTM encryption (that it's easy to crack - that it uses simple XOR). And the information that it uses a 16-bit key is from another person's website. And if I look at the packetlist I see it uses a 32-bit key not a 16-bit key but someone else told me it was 16-bit and I asked him if he was sure and he said "Yes!". And I trusted him even if he didn't seem to know about what he was talking (I don't mean anyone in the forum here).

You don't have to shoot my ideas down even if I am not as experienced as you are.
Mr Ekted - Mon Feb 16, 2004 8:10 am
Post subject:
Qndre wrote:
No I am not. I trust in the information other people (who say they are experienced) give to me that's all. I haven't tried out so much with the Subgame2 server and it seems like I am not as experienced as you are. But you don't have to shoot my little knowledge down even if you know more than I do. I don't know much about it. If I would then I wouldn't have come here. Another person (who said he had worked on a Continuum client) gave me the information about the CTM encryption (that it's easy to crack - that it uses simple XOR). And the information that it uses a 16-bit key is from another person's website. And if I look at the packetlist I see it uses a 32-bit key not a 16-bit key but someone else told me it was 16-bit and I asked him if he was sure and he said "Yes!". And I trusted him even if he didn't seem to know about what he was talking (I don't mean anyone in the forum here).

You don't have to shoot my ideas down even if I am not as experienced as you are.


I am not "shooting your ideas down". I am telling you that you are flat wrong. You said you trust people who say they have experience, but you won't listen to what anyone is telling you here. Continuum encryption is not 16-bit and it has not been cracked and it is not easy. Only 1 person worked on that aspect of Continuum, and he didn't share the code with the only other person who worked on it (me). Note that XOR is a perfectly secure method of encryption as long as the keystream is extremely difficult to reproduce. You are showing your inexperience when you make stupid claims.

If you want information, ask. People will answer your questions as appropriate to your level of understanding, which is pretty damn low. Don't try and tell us what we know. Many of us have been involved with this game for over 7 years. If you are anywhere near as good as you keep claiming, you would not be asking retarded questions, you would be showing us a new client and asking us to test it for you.[/b]
Smong - Mon Feb 16, 2004 8:14 am
Post subject:
Can you post links to all the sources you have found? The source you posted previously was only SS API from sf.net (see my last post).
Mr Ekted - Mon Feb 16, 2004 8:15 am
Post subject:
Here's a little newbie test for you Qndre:

Make a console app that logs into the SSCU Trenchwars Subspace server. All it has to do is login successfully then logout. You only have to handle about 10 packet types or so. I'll even start you off...

Code: Show/Hide
int main (int argc, char *argv[])
{
return 0;
}

Qndre - Mon Feb 16, 2004 8:45 am
Post subject:
Mr Ekted wrote:
Here's a little newbie test for you Qndre:

Make a console app that logs into the SSCU Trenchwars Subspace server. All it has to do is login successfully then logout. You only have to handle about 10 packet types or so. [..]

Sorry. I've never made anything in C before except a "Hello World Application". biggrin.gif I only have programming experience in Basic. icon_sad.gif
So it can take some time. TW doesn't support the old VIE client. I've still got Subspace 135 installed but I can't join TW.
Mr Ekted - Mon Feb 16, 2004 8:59 am
Post subject:
Please lock this thread now.
Qndre - Mon Feb 16, 2004 9:09 am
Post subject:
Mr Ekted wrote:
Please lock this thread now.

If you don't want to be informed about the details of CTM encryption...
Dr Brain - Mon Feb 16, 2004 10:02 am
Post subject:
We don't.
CypherJF - Mon Feb 16, 2004 10:22 am
Post subject:
Mr Ekted wrote:
Here's a little newbie test for you Qndre:

Make a console app that logs into the SSCU Trenchwars Subspace server. All it has to do is login successfully then logout. You only have to handle about 10 packet types or so. I'll even start you off...

Code: Show/Hide
int main (int argc, char *argv[])
{
return 0;
}



LoL... icon_wink.gif good stuff good stuff
Cyan~Fire - Mon Feb 16, 2004 11:10 am
Post subject:
Oh wow Ekted, that code is awesome! I think I'll design my own Continuum-encryption client now! Thanks!
Mr Ekted - Mon Feb 16, 2004 11:46 am
Post subject:
That code is copyrighted by me. I'll sue! icon_smile.gif
Qndre - Mon Feb 16, 2004 11:49 am
Post subject:
OK. I'll stop posting here. If someone who reads this thread is really interested in my work please email me: subspace@qndretreff.de
Please give me the subject "Open Power Games III" so that I don't delete it if I think it's spam.
So if someone wants to help me or wants to know how I solved the problem with the CTM encryption please do the same and I'll respond as fast as possible.

Thanks, Qndre


Maybe I'll solve the Problem this way:
Mine GO BOOM wrote:

This could possibly be done in any language, as Grelminar is attempting to allow, but most likely will end up being C, as it isn't too hard to do what you'd need from the server's point of view. This plugin will have full, always-updated access to everyone's positions, player, balls, or flags. You can then have it do a HTML POST/GET request to your webserver's PHP script, or the better choice if possible, update your SQL database directly.


At first your responses were useful but now... icon_cry.gif
I'm sorry my idea has to end like this. I'll try to realize it on my own and I'll contact PriitK and ask him if it's allowed to do so.


My last comment:
Mine GO BOOM wrote:

I'm sorry to shoot down your idea, as it is a good one

Why do you do it then? If you don't know how to solve the problem then say "I don't know". I also don't know everything. But then I say "I don't know." and not "That's a shit and you are stupid."![/quote]
Mine GO BOOM - Mon Feb 16, 2004 12:21 pm
Post subject:
Qndre wrote:
OK. I'll stop posting here.
...
Why do you do it then? If you don't know how to solve the problem then say "I don't know". I also don't know everything. But then I say "I don't know." and not "That's a shit and you are stupid."!

I personally wouldn't stop posting because of other people's responces as long as you still have the chance to learn, but I still feel my first statement is true. The way you are attempting to go about this is impractical.

Give ASSS a try. It is much simpler to write for, and also allows you to create your own custom protocol to communicate with whatever client you wish to design, be it an SQL database on a website, or some executable users run.

I'm curious myself to email you, questioning about what knowledge or assumptions you have about Continuum's encryption, but, from your understanding of checksums, I'm worried about your responce(s) to any queries. If you'd like to discuss this in private, my email address is about everywhere.

Good luck.
Qndre - Mon Feb 16, 2004 1:49 pm
Post subject:
Mine GO BOOM wrote:
[..]
Give ASSS a try. It is much simpler to write for, and also allows you to create your own custom protocol to communicate with whatever client you wish to design, be it an SQL database on a website, or some executable users run.

I'm curious myself to email you, questioning about what knowledge or assumptions you have about Continuum's encryption, but, from your understanding of checksums, I'm worried about your responce(s) to any queries. If you'd like to discuss this in private, my email address is about everywhere.

Good luck.

Give ASSS a try? OK - I'll try but there are two problems I see:
1. Almost no zone uses ASSS. And I don't believe people want to spec little zones with 2 users in it. People want to spec TW with 600 users. biggrin.gif And if I have to write a custom protocol for it... no zone would let me do.
2. My knowledge about ASSS is 0. But maybe I can learn something about it but I guess it isn't simple.
_
Continuum Decryption: (found on an I-AM-SUBSPACE-ADDICTED-WEBSITE)
Look at the comment. It's not only Subspace but Continuum:
Quote:
// SS = 1, Ctm .36 = 16, Ctm .37 = 17

First how you get the key:
Code: Show/Hide

      temp = (uint32)((uint64)((uint64)key * (uint64)0x834E0B5F) >> 48) + (temp >> 31);
      key = ((key % 0x1F31D) * 16807) - (temp * 2836) + 123;


Then how to decrypt
Code: Show/Hide

// Decrypts the packet in-place.
uint16 SSEncryption::GetType() const
{
   return 0x0001;      // SS = 1, Ctm .36 = 16, Ctm .37 = 17
}

bool SSEncryption::Decrypt(SSPacket & packet)
{
   ClearError();

   if(!m_bEncrypting)
      return false;

   uint32 packetLen = packet.GetLength();
   assert(packetLen <= 520);
   if(packetLen > 520)
   {
      SetError("[SSEncryption::Decrypt] - Packet length %d is too long for SubSpace decryption.", packetLen);
      return false;
   }

   uint32 decrypted = m_uiKey;
   uint32 startpos = 1;

   if(!packet[0])
      ++startpos;

   for(uint32 cnt = startpos; cnt < packetLen; cnt += 4)
   {
      uint32 encrypted = packet.GetDword(cnt);

      decrypted ^= SS_GetDword(m_auiKeystream, cnt - startpos) ^ encrypted;
      packet.SetDword(decrypted, cnt);
      decrypted = encrypted;
   }

   return true;
}

_
PS: They banned me from TW till 21st February 2004 because I asked for the source of Continuum.
Pure_Luck - Mon Feb 16, 2004 2:13 pm
Post subject:
You were banned from Trench Wars because you were a newbie and were teamkilling. Nothing to do with you asking for the continuum source code. Thanks for the good read though. Pretty comical posts. -Pure_Luck
Qndre - Mon Feb 16, 2004 2:17 pm
Post subject:
Pure_Luck wrote:
You were banned from Trench Wars because you were a newbie and were teamkilling. Nothing to do with you asking for the continuum source code.

That's not right. The MOD told me: "Do not abuse ?help command - we told you that we are not aware of the source. We will ban you now."
And I asked: "Am I allowed to ask PriitK for the source." And he said: "Of course."
Pure_Luck - Mon Feb 16, 2004 2:19 pm
Post subject:
That mod was me. And that was completely different from the situation of your teamkilling.


Mon Feb 16 13:24:25: Qndre: *warn This is your last warning. Please do not teamkill or it will result in a 3 day ban.

Then you teamkilled and were banned. Good try though. Have a nice vacation.


Pure_Luck
Qndre - Mon Feb 16, 2004 2:21 pm
Post subject:
If you were the MOD then you'd know that you told me
Quote:
not to abuse ?help command

.
CypherJF - Mon Feb 16, 2004 2:24 pm
Post subject:
take it somewhere else gentlemen; topic moving on...
nintendo64 - Mon Feb 16, 2004 3:06 pm
Post subject:
Sadly, this topic belongs in the trash... Qndre wherever you find those encryption sources let me remind you READ BACK what we all said.

-nintendo64
Mine GO BOOM - Mon Feb 16, 2004 3:23 pm
Post subject:
Qndre wrote:
Continuum Decryption: (found on an I-AM-SUBSPACE-ADDICTED-WEBSITE)
Look at the comment. It's not only Subspace but Continuum:
Quote:

If you notice, that is only Subspace decryption. The one byte that he lists there takes about which Continuum encryption method the server/client wish to use. It is sent in plain text, and easily sniffed.

As for the banning, that has nothing to do with creating a new client...
ExplodyThingy - Mon Feb 16, 2004 3:27 pm
Post subject:

Mr Ekted - Mon Feb 16, 2004 4:00 pm
Post subject:
That source code posted is almost the SS (VIE) encryption. It is missing some small, but important lines. The SS encryption algorithm is published in lots of places and is known by many people, including all bot core developers. It is useless to you for writing a Continuum client.

Too bad Qndre has no idea what the source code means. Where it says "key" in the first part...that is not the key to the encryption. Its just a badly named local variable.
Qndre - Tue Feb 17, 2004 7:41 am
Post subject:
Mr Ekted wrote:
That source code posted is almost the SS (VIE) encryption. It is missing some small, but important lines. The SS encryption algorithm is published in lots of places and is known by many people, including all bot core developers. It is useless to you for writing a Continuum client.

Too bad Qndre has no idea what the source code means. Where it says "key" in the first part...that is not the key to the encryption. Its just a badly named local variable.

1. There are some lines which aren't included in the source I found? No real problem. But thanks that you informed me. I've found a more complete algorithm in the source of Snrrubs client (which is still in beta).

2. It's useless for writing a Continuum client? I don't agree. If it's only VIE encryption then it might be useless for Force-Continuum-Zones but I can write a Subspace client with it and my later Continuum client should also be able to join old VIE zones. And in "Force-Continuum-Zones": What if I send "Continuum" in the version bytes to the server but a VIE (old Subspace) encryption key and start using VIE encryption and security checksums of the "subspace.exe"? I guess the server won't believe that I am a Continuum client because if use the old encryption but new version bytes but maybe it only checks what's in the version bytes. If it only checks the version byte then I've won.

3. I'll start writing a new version of the "Encryption Cracker" included in my software package "nuetzliche tools" for CTM encryption now and a new version of the "Packet Check" also included in "nuetzliche tools". The "Packet Check" should be able to send UDP packets. (maybe I can figure out how to block packets like a firewall does and then editing them and then sending them out - that would be perfect) If I check the I/O of the server maybe I can figure out the encryption. But if the encryption uses a continuous keystream I probably won't.

Thank you very much for your interest in this project. (I know not all are interested - some people think it's crap but if you think so then PLEASE say it once and then don't start an argument. Thanks.)

PS: If this thread will be blocked maybe we can go to my own forum and continue the discussion. I won't write the URL here because most forum-owners don't like that. If you are interested please email me.
Anonymous - Tue Feb 17, 2004 8:07 am
Post subject:
This thread likely will not be closed, and because Mikes not an egotist, he probably wont get mad if you link to your forums. I link to ssforum.net quite often from here.

Dont get it wrong, most of us are very interested in seeing this work. But we are also being realistic. Id love to do this myself, but im working on simpler things first to get my feet wet, something I recommend you do. For example, write some programs in C/C++ that do what youve got in Basic and JavaScript. THen write a basic (as in simple) VIE-encryption bot, learn how C/C++ works with sockets and all that crap. Develop your skills in this area before diving in head first. It will save you a lot of headache I assure you.

If you are honestly serious about this, I hope you keep with it, and post as needed. But please, if Ekted or MGB says you have a misconception, or you have downloaded something that isnt what you think it is, trust them. I assure you, they know what theyre doing.
Mr Ekted - Tue Feb 17, 2004 8:32 am
Post subject:
If you tell the server you are VIE or Cont, you must use the expected encryption or the server will boot/ignore you for sending junk.

The majority of the encryption code for Cont exists only in the client. I didn't exactly understand this when I first heard it, but it is a very clever solution. Yes, you should be able to just swap VIE for Cont encryption at any point by just replacing that specific layer of the networking code, but Cont is more than just encryption. You will also need to handle LVZ, object packets, all the new settings added to the arena data structure, etc.

Obvisouly, the biggest problem with your potential success is security. If you were able to make a client that looked like a Cont client to the server, and you published the source code, every hacker that plays SS would be able to write instant cheats. This would require a big change to the encryption system and new client EXE protection, rendering your client invalid. One of the big reasons for making a new client in the first place was this very issue: make the encryption difficult enough that it would takes months-to-years for an experienced ASM programmer to crack, but only a day for us to change.
Qndre - Tue Feb 17, 2004 9:07 am
Post subject:
Explody wrote:
Dont get it wrong, most of us are very interested in seeing this work. But we are also being realistic. Id love to do this myself, but im working on simpler things first to get my feet wet, something I recommend you do. For example, write some programs in C/C++ that do what youve got in Basic and JavaScript. THen write a basic (as in simple) VIE-encryption bot, learn how C/C++ works with sockets and all that crap. Develop your skills in this area before diving in head first. It will save you a lot of headache I assure you.

If you are honestly serious about this, I hope you keep with it, and post as needed. But please, if Ekted or MGB says you have a misconception, or you have downloaded something that isnt what you think it is, trust them. I assure you, they know what theyre doing.

I believe that MGB knows what he's doing because he seems to be very experienced. But if I wrote some programs in C that would end in a disaster. icon_confused.gif
I really don't know anything about C. And I don't really want to LEARN C because I only see a hash of commands if I look at C code.
I can write Perl, PHP, JavaScript, DHTML, CSS but I don't think that this helps me much in this project. The only programming language (I am able to write yet) which could help me (because I know it can manage graphics and network access) is Basic. icon_sad.gif
Don't laugh at it because Basic is a real powerful language. I've written some programs in WDL... Some 1st person 3D games... And WDL is a bit like C.
_
Mr Ekted wrote:

The majority of the encryption code for Cont exists only in the client. I didn't exactly understand this when I first heard it, but it is a very clever solution.

I don't understand. So if the encryption code if only in the client and not in the server then the server can't check if my encryption is correct or if I only send trash to it. So if the server can't check the encryption then I can send nearly any packet, even unencrypted ones. If I log in using the 00 01 core packet then I get a 00 05 response. I don't see where it is encrypted? You told me that CTM encryption even encrypts the packet headers so why do I see them then? I really don't understand much of this stuff.[/quote]
Mr Ekted - Tue Feb 17, 2004 9:28 am
Post subject:
The connection packets can't be encrypted because then the server wouldn't know how to decrypt them. The client decides on the encryption key.

If you are going to run a server for Cont, the first thing you do is use the Cont client to generate a set of very large encryption tables. These tables are different every time you generate them. The server knows how to use the tables, but it doesn't know how to make them. Cont tells the server a key which the server uses to access the tables. Cont doesn't need the tables because it can generate what it needs on the fly. So the real "meat" of the problem only has to exist in one place. Pretty cool.
Anonymous - Tue Feb 17, 2004 9:46 am
Post subject:
Mr Ekted wrote:
[..] The client decides on the encryption key. [..]

So I set the key to FF FF FF FF and then I'll only have to invert the data I get and the data I send because XOR 11111111 is the same as invertion and then I've got the plaintext.

Example:

Code: Show/Hide

    10010101
XOR 11111111
=   01101010

Smong - Tue Feb 17, 2004 10:28 am
Post subject:
Mr Ekted wrote:
If you are going to run a server for Cont, the first thing you do is use the Cont client to generate a set of very large encryption tables. These tables are different every time you generate them.
So in Asss, the security module unpacks the Continuum binary, executes a portion of the code (under Linux) to make the tables (using a lot of RAM to store them I presume).

And the tables are different every time the server loads the security module? Doesn't that mean the server must tell the client some info, to make sure they are using the same stuff (I hesitate to use the word tables, as you said the client can do it OTF)?

Or is part of the code in Continuum used to generate these tables, then they are hardcoded into the server before release? (ie, scrty and scrty1).
Mr Ekted - Tue Feb 17, 2004 11:07 am
Post subject:
Anonymous wrote:
[..]
So I set the key to FF FF FF FF and then I'll only have to invert the data I get and the data I send because XOR 11111111 is the same as invertion and then I've got the plaintext.


LOL no. The key is not XOR'd with the data. That would be simple encryption. The key is used to generate a keystream which is XOR'd with the data. The VIE keystream generator is about 8 lines of C. The Cont keystream generator is probably > 1000 lines of C, which is probably > 10,000 lines of ASM.
Qndre - Tue Feb 17, 2004 11:26 am
Post subject:
Smong wrote:
[..]

So in Asss, the security module unpacks the Continuum binary, executes a portion of the code (under Linux) to make the tables (using a lot of RAM to store them I presume).

And the tables are different every time the server loads the security module? Doesn't that mean the server must tell the client some info, to make sure they are using the same stuff (I hesitate to use the word tables, as you said the client can do it OTF)?

Or is part of the code in Continuum used to generate these tables, then they are hardcoded into the server before release? (ie, scrty and scrty1).

Yes. You have a continuous bitstream between the server and the client. And there is a keystream and a bitstream. At example:

Bitstream: 100101110010010100010101011110010101000101001111
Key: 11010010101010101100110010100111

In this example the bitstream is 48 bit long (6 bytes - in reality it's "inifinite"). The key is 32 bits long (4 bytes - in reality it's also 4 bytes). Now you make the key as long as the bitstream by putting many keys after each other so the resulting stream is as long as the bitstream.

So if the key is 32 bits long and you need 48 bits to fill the whole example bitstream you'll have to take the first 16 bytes of the key again because 32+16=48. Then the keystream is as long as the bitstream (in reality you have to repeat the keystream over and over again because the bitstream can be up to infinite long depending on how long you are in game). Now if we generate the keystream out of the key then we have:

Code: Show/Hide

Bitstream: 100101110010010100010101011110010101000101001111
Keystream: 110100101010101011001100101001111101001010101010
Key:       11010010101010101100110010100111


Now we XOR the Bitstream with the keystream we generated and then we have:
010001011000111111011001110111101000001111100101

That's the plaintext.


But the most real encryption don't work like that. But I guess Continuum does but that's just a guess (if you say "no" then I can believe in that or try it out - I'll try it out biggrin.gif )

They might have an algorithm which makes a more-complex keystream out of the key. At example they could shift every byte of the key left (the first byte one bit, the second byte two bits) and then XORing them all (like a checksum function like MD5 would do).

Then they get a new key which they can use. But that isn't the best idea because the keystream would get periodic after a short period of time (the period it takes with MD5 is very long because it's a very PROFESSIONAL encryption).

So you can take another formula to calculate new keys. A very simple solution would be to add one (+1) to the key. Then if you have 1 as the key the next byte would be encrypted with 2 and the next with 3 and the next with 4 and the next with 5 and the next with 6 and so on... Maybe until 65535 and then reset to 0 if you had a 16-bit key. But that would be too easy because an experienced programmer would recognize it. So I guess they use the keystream method I explained first and if the keystream is random
Quote:
int(rnd*65535)

at example then it should be hard to crack. But if you can get the keys out of the chipertext then you've won because then you'd just have to combine the chipertext with the key and you've got unencrypted plaintext.[/code]

Mr Ekted wrote:

The key is used to generate a keystream which is XOR'd with the data. The VIE keystream generator is about 8 lines of C.


Oh - in the topic review I see you just posted a thread which is almost like my one. I didn't steal your idea. We just had the same. biggrin.gif

Quote:

The Cont keystream generator is probably > 1000 lines of C

You want to fool me? The whole Continuum is not that long. biggrin.gif My self-written GUI is about 4000 lines in BASIC (not C) but CONTINUUM?? *laugh*[/quote]
Anonymous - Tue Feb 17, 2004 12:57 pm
Post subject:
Qndre wrote:

You want to fool me? The whole Continuum is not that long. My self-written GUI is about 4000 lines in BASIC (not C) but CONTINUUM?? *laugh*


EDIT: If you'd like to see the image that was posted with this message the IMG URL is: http://www.tm001d6792.pwp.blueyonder.co.uk/stfu46.jpg
Mr Ekted - Tue Feb 17, 2004 1:36 pm
Post subject:
Qndre, a keystream is not taking the key and replicating many times. Why don't you believe anyone here? Everything I have told you is true, and every time I post an honest reply to you, you treat me as if I'm lying. You say you came here for help, and you call me a liar when I offer it. So start listening or fuck off.
Mr Ekted - Tue Feb 17, 2004 1:39 pm
Post subject:
I just added up the lines in just the .cpp files for the Cont menu alone. The total is 25,600 lines. Menu is 330K, exe is 420K. You decide.
Qndre - Tue Feb 17, 2004 2:18 pm
Post subject:
Mr Ekted wrote:
[..] Why don't you believe anyone here? Everything I have told you is true, and every time I post an honest reply to you, you treat me as if I'm lying. You say you came here for help, and you call me a liar when I offer it. So start listening or fuck off.


1. I never said any of you were lying. I'm sure that MGB knows what he's talking about. I know it because he showed much expertise and knowledge. The other ones said I'd be studid in every second thread they posted. And I simply can't trust in anyone who calls me stupid. You understand?

2. I've got an online contact who helped by the development of the Continuum client. He told me something else. I trusted him.

3. I see the result I/O of Shanky-Server and Continuum client at my sniffer. I don't know much about networking protocols but I know some basics. And some of your statements doesn't fit with my knowledge. Maybe I am wrong but ...

4. I see source code of other experienced people like of Snrrrub. I don't understand it very well but I can see how long it is. It's not 1000 lines. And if some of you say it's 1000 lines then I can't believe because I see the source. And if I see source code on other people's website... And if I see them on many websites which all tell nearly the same... Why should they be lying? Why should they tell something wrong? They want to fool their visitors?

5. PriitK has written Continuum, not a company. Continuum is running on private servers. Why should one person write such a long source? Why should he use a very secure encryption? Continuum is a very basic game (2D top-view, massively multiplayer, no ray-tracer needed, plain 256 colors, only BMP graphics cut together). What should be so secure in it?

6. I see the official information people of Continuum give to me. Once in the news of an official Continuum zone I read that thousands of passwords were stolen? How was that possible if the encryption is so "uncrackable"?

7. In forums a lot of trash is written together. I made the experience that people often don't want to help forum users but turn them crazy or show the others how "stupid" they are.

8. All these things play together. The information I get from other people I trusted in ... Almost everyone of these people told me the same.

9. I've got informations that are very very different of those you give to me. I read Continuum was open-source. Snrrubspace has written another client. How was he able to do that if no one except PriitK has the source.

I don't want to say that you are lying because I don't know and I also don't believe that all of you would do but I get different information from everyone I ask. Some people of those can't tell the truth because it's too different.

Please don't take it too serious. I didn't want to insult anyone of you.
Mr Ekted - Tue Feb 17, 2004 3:41 pm
Post subject:
Quote:
1. I never said any of you were lying. I'm sure that MGB knows what he's talking about. I know it because he showed much expertise and knowledge. The other ones said I'd be studid in every second thread they posted. And I simply can't trust in anyone who calls me stupid. You understand?


MGB is far from being a competent programmer in my opinion, but he's way above you.

Quote:
2. I've got an online contact who helped by the development of the Continuum client. He told me something else. I trusted him.


PriitK and I are the only ones who worked on Cont. There are no other Cont-compatible clients.

Quote:
3. I see the result I/O of Shanky-Server and Continuum client at my sniffer. I don't know much about networking protocols but I know some basics. And some of your statements doesn't fit with my knowledge. Maybe I am wrong but ...


Then your knowledge is wrong. Face it. You have come into a group of experts with no knowledge yourself. You keep quoting "friends" who tell you stuff, and that this overrides what we tell you here. Show us anything that you say is true: a url, some source.

Quote:
4. I see source code of other experienced people like of Snrrrub. I don't understand it very well but I can see how long it is. It's not 1000 lines. And if some of you say it's 1000 lines then I can't believe because I see the source. And if I see source code on other people's website... And if I see them on many websites which all tell nearly the same... Why should they be lying? Why should they tell something wrong? They want to fool their visitors?


Menu.dll is 25,600 lines of C. I wrote it. I know. I'm looking right at it. Call me a liar again why don't you.

Quote:
5. PriitK has written Continuum, not a company. Continuum is running on private servers. Why should one person write such a long source? Why should he use a very secure encryption? Continuum is a very basic game (2D top-view, massively multiplayer, no ray-tracer needed, plain 256 colors, only BMP graphics cut together). What should be so secure in it?


Before Cont, cheating was rampant. There were apps you could run to give yourself unlimited weapons, speed, and energy. Cont saved Subspace.

Quote:
6. I see the official information people of Continuum give to me. Once in the news of an official Continuum zone I read that thousands of passwords were stolen? How was that possible if the encryption is so "uncrackable"?


Passwords were stolen in 2 ways. There was a bug in the packet handling for banners which allowed VIE Clients to get back buffers full of junk that ocassionally had remnants of a login packet. Since VIE encryption was already known it was easy to decode. The other was a trojan/browser flaw that uploaded profile.dat. This file used to contain passwords associated with your logins. It does not anymore.

Quote:
7. In forums a lot of trash is written together. I made the experience that people often don't want to help forum users but turn them crazy or show the others how "stupid" they are.


I don't care how inexperienced a person is. If they have a desire to dive in and learn, that's great. But when you start talking like you are some kind of expert, and it's clear you are barely able to speak without making a fool of yourself (see discussion of MD5 or keystreams) and you contradict what people are telling you--who actually wrote the stuff--you are not likely to be well-received.

Quote:
8. All these things play together. The information I get from other people I trusted in ... Almost everyone of these people told me the same.


Every statement you have made from yourself or from an outside source has been wrong. I can't put it any simpler than that.

Quote:
9. I've got informations that are very very different of those you give to me. I read Continuum was open-source. Snrrubspace has written another client. How was he able to do that if no one except PriitK has the source.


Cont is closed-source. Period. Snrrrub wrote his client from scratch, and it is a VIE client. Some people can actually figure things out on their own you know. I wrote my SS bot system from scratch. Catid wrote MERV bot system from scratch.

Quote:
I don't want to say that you are lying because I don't know and I also don't believe that all of you would do but I get different information from everyone I ask. Some people of those can't tell the truth because it's too different.


Why would people who program for and play Subspace want to deceive you? If you truly think this forum is some huge conspiracy to trick you, then stop hanging out here. Otherwise start paying attention.
Mine GO BOOM - Tue Feb 17, 2004 4:08 pm
Post subject:
  1. I agreed with Ekted, I'm not the best around the block. My code works, but barely. I learn by looking over other's works, and seeing their styles and methods for fixing problems. The first project I worked with and learned from was written by Ghost Ship, and trust me, that isn't the way to start.

  2. Priit made exe, Ekted made the menu and chat screen. Ekted told Priit how to access his dll, and Priit added that to exe. There are a few, like two, people who have access to Priit's code atleast, but trust me, you would never be able to get it from them either. They play SS as much as Priit now.

  3. My only comment is Shanky gets way too much credit because of my Server Help site. I help people and made the site, its called Shanky's Server Help by others. Priit and VIE made the server software, Shanky gets credit for it. All because he bought a domain name before me...

  4. You might want to double-check your answer. Maybe you are looking at only one file?

  5. Just because one person made it doesn't mean it has to suck ass. I've personally believe the less people working on a project, usually the better the final outcome is, even if it takes longer.

  6. Ever heard of the problems with Netscape's Secure Socket Layer (SSL)? The SSL encryption itself, which is used everytime you go to an https site, or see that little lock icon on your browse lock up, was perfect. But people were able to still get information from the data, because their method for creating a random number for the SSL connection was flawed. Thus, instead of checking 1024 bits or whatever, you could actually reproduce the original key exchange down to a possibility of practical size in which you could then brute-force those few keys. So an encryption is only as secure as what it is built on.
    Better example for those who watch movies. Seen the Matrix? Guess how they got into that one super-secret door? They abused the security system that the other system was built on. Find one weak chain, and abuse it to get what you need.

  7. Forums are only populated by people to my knowledge. I havn't had a cat or a horse sign up. People act like this in real life too. Bosses could be complete idiots. Co-workers the biggest slackers that put Wally to shame. You have to learn to deal with a few bad people along the way. It isn't hard to ignore users. A few people annoying you? Add them to your ignore list and you won't have to care. Thus, you can filter out the idiots, and keep the information you want from the good people. So far, only two people have a user on their ignore list in the 2+ years this forum has been online. And one of those users is ignoring me at that.

  8. Did you know the moon is made a cheese? That eggs are really green inside the shells, but once you crack it, the air gets in and changes the colors.
    You need to learn to filter out information. Just because you see on TV people talking about Michael Jackson raping little boys doesn't mean its true.

  9. Read my responce labeled #2.


Please, for the love of god, don't believe us. Take what others say with a grain of salt. Figure it out for yourself. I know that when I was first figuring out the SS protocol, I asked Ekted a few questions in which he helped me with (thanks still, I do give you credit in my horribly commented source). But there was a few things in which the way I interpreted the things he said, or maybe even what information he knew at the time, was incorrect. I didn't "Oh, that has to be right, I'll just throw it in and assume it works flawlessly". I did some tests on it to see if it was correct. If it was, I learned the methods about it, and gave me a better understanding of the topic. If it didn't work, I debugged it and see if there was anything I could learn from that to figure out the whole picture.

Be a critical thinker. Just because all your Christian friends say that it you don't believe in God doesn't mean you'll go to hell. They maybe right, they maybe wrong. But you need to figure it out for yourself.
nintendo64 - Tue Feb 17, 2004 6:39 pm
Post subject:
i will just like to add something, Qndre why do you keep asking the same Questions over and over? they are already answered few pages back go read them again...

Example:


Question On Page 8
Qndre wrote:
[..]
2. It's useless for writing a Continuum client? I don't agree. If it's only VIE encryption then it might be useless for Force-Continuum-Zones but I can write a Subspace client with it and my later Continuum client should also be able to join old VIE zones. And in "Force-Continuum-Zones": What if I send "Continuum" in the version bytes to the server but a VIE (old Subspace) encryption key and start using VIE encryption and security checksums of the "subspace.exe"? I guess the server won't believe that I am a Continuum client because if use the old encryption but new version bytes but maybe it only checks what's in the version bytes. If it only checks the version byte then I've won.


Answered On Page 3
nintendo64 wrote:
Qndre, what you say actually doesn't works on ForceContinuumOnly Zones, i know this, but i decided to try.

00 01 Encryption Request Packet with the Continuum Encryption version 11 (VIE is 1)
I did the 00 01 00 00 00 00 11 00
I got a reply of 00 10 Packet an ACK used to start the Encryption Sequence which i cannot start with the VIE Encr scheme i got on my bot.

Then i tried a
00 01 Encryption Request Packet with the SubSpace Encryption Version 01 (CTM is 11)

i did 00 01 00 00 00 00 01 00
i didn't get any reply, the Subgame let my SS Bot on hold.

btw 0x24 is 36 you should use 0x27 which is 39 and 0x86 is 134.

Also do a *einfo on the application you did the Login session, you won't see a CTM if you logged in with a Sysop Password, it will say VIE 0.36 on your case because you used 0x24, if you had used 0x86 it'll say 1.34.

A note here Sysop can enter with a SubSpace Client to force only Continuum zones.

Well good luck trying to figure out a Continuum Session.

-nintendo64


In case you didn't understand the answer i provided if you do put 0.36 or what ever in the version it will appear as VIE (number you put as version). The encryption is the only method the server uses to differentiate between VIE and Continuum.

-nintendo64
Mr Ekted - Tue Feb 17, 2004 6:53 pm
Post subject:
Connection sequence for all clients is:

C 00 01 connection request
S 00 05 sppof check
C 00 06 spoof reply
S 00 02 connection reply
C 00 03 xx xx xx xx 09 login (reliable)
S 00 03 xx xx xx xx 0a login result (reliable)
CypherJF - Wed Feb 18, 2004 2:16 am
Post subject:
Did Qndre say Snrrrub space is open-source? If so, is there a site with it on there for download? -- or would I have to talk to Snrrrub about it sometime?

Adios...
cypher

p.s. i don't know if anyone cares, but these last 9 pages have given me some _new_ insight to how the SS Protocol is handled icon_smile.gif yey! lol... *cheers*
CypherJF - Wed Feb 18, 2004 2:20 am
Post subject:
Also, since Priit holds all the source-code, and etc. and we know how VIE server's work; why hasn't anyone begun work on a new Client/Server combo, since it seems he won't do anymore devel. on it?
Does it essentially come down to, people do not have < insert time/patience/money/resources/any/both/etc > to complete it?

But there again, if it's not broken, don't fix it. Being that the community has accepted and is relying on Continuum -- it'd seem kinda pointless to begin a new client/server package... But yeah...

Sorry, my brain is just wondering and raddeling off questions... :/
Qndre - Wed Feb 18, 2004 7:19 am
Post subject:
Uff... This reply will get a bit long but please take the time to read it. biggrin.gif
Mr Ekted wrote:

MGB is far from being a competent programmer in my opinion [..]

That's a matter of opinion.
Mr Ekted wrote:

but he's way above you.

That's right. No doubt.
Mr Ekted wrote:

PriitK and I are the only ones who worked on Cont. There are no other Cont-compatible clients.

If you know this for sure that I won't ask anyone of these people again who told me they were also working on it.
Mr Ekted wrote:

Then your knowledge is wrong.

Would that be unusual? I can't know everything. I'm here to learn, not to success.
Mr Ekted wrote:

Menu.dll is 25,600 lines of C. I wrote it. I know. I'm looking right at it. Call me a liar again why don't you.

I don't because I believe in what you tell me.
Mr Ekted wrote:

Before Cont, cheating was rampant. There were apps you could run to give yourself unlimited weapons, speed, and energy. Cont saved Subspace.

That must be true because everyone told me nearly the same.
Mr Ekted wrote:

The other was a trojan/browser flaw that uploaded profile.dat. This file used to contain passwords associated with your logins.

That's right. Already heard of it from Subspace related websites and MODs in zones.
Mr Ekted wrote:

I don't care how inexperienced a person is. If they have a desire to dive in and learn, that's great. But when you start talking like you are some kind of expert [..]

I'm definitly NO expert.
Mr Ekted wrote:

Every statement you have made from yourself or from an outside source has been wrong. I can't put it any simpler than that.

Sad but true some people's knowledge (including mine) is nearly 0.
Mr Ekted wrote:

Cont is closed-source. Period. Snrrrub wrote his client from scratch, and it is a VIE client.

Some people tell me this some people tell me that. Because I've never seen the original source of Continuum I believe in what you say.
Mr Ekted wrote:

If you truly think this forum is some huge conspiracy to trick you, then stop hanging out here. Otherwise start paying attention.

I'll choose the second solution because slowly I begin to understand what's going on with other PPL who said they 've written Cont client, etc... And I don't believe that all of you are lying just to fool me. Why should you do? The PPL who told me the whole shit want to fool me so that I say "Wow - he's great - he has written a Cont client!". I guess they want me to pay attention even if they haven't done anything like this before.
Mine GO BOOM wrote:

My code works, but barely. [..]

If it works then it's really good. My code doesn't work. icon_sad.gif
Mine GO BOOM wrote:

[..] but trust me [..]

Quote:

Never trust a person who says "trust me".

*joking around* biggrin.gif
Mine GO BOOM wrote:

My only comment is Shanky gets way too much credit because of my Server Help site.

So it's actually YOUR site? *wow*
Mine GO BOOM wrote:

I've personally believe the less people working on a project, usually the better the final outcome is, even if it takes longer.

Matter of opinion... I thing if there are too many people then it's shit. But two or more are good.
Mine GO BOOM wrote:

The SSL encryption itself, which is used everytime you go to an https site, or see that little lock icon on your browse lock up

I know what SSL is. I'm not as stupid as you think.
Mine GO BOOM wrote:

Seen the Matrix?

Yes! Of course!! I think it's the best film I've ever seen.
Mine GO BOOM wrote:

[..] few people annoying you? Add them to your ignore list and you won't have to care. Thus, you can filter out the idiots, and keep the information you want from the good people.

I don't need a tool to ignore people.
Mine GO BOOM wrote:

Be a critical thinker. Just because all your Christian friends say that if you don't believe in God doesn't mean you'll go to hell. They maybe right, they maybe wrong. But you need to figure it out for yourself.

That's a good advice. Thanks! I'm just believing everyone even if he is an idiot. Most mistakes are made are because of that.
Nintendo64 wrote:

i will just like to add something, Qndre why do you keep asking the same Questions over and over? they are already answered few pages back go read them again...

Sorry.
Nintendo64 wrote:

Qndre, what you say actually doesn't works on ForceContinuumOnly Zones, i know this, but i decided to try.

00 01 Encryption Request Packet with the Continuum Encryption version 11 (VIE is 1)
I did the 00 01 00 00 00 00 11 00
I got a reply of 00 10 Packet an ACK used to start the Encryption Sequence which i cannot start with the VIE Encr scheme i got on my bot.

Then i tried a
00 01 Encryption Request Packet with the SubSpace Encryption Version 01 (CTM is 11)

i did 00 01 00 00 00 00 01 00
i didn't get any reply, the Subgame let my SS Bot on hold.

Already tried this out on my own. Server doesn't accept a nul-key (00 00 00 00), but a full-key (FF FF FF FF).
Mr Ekted wrote:

C 00 01 connection request
S 00 05 sppof check
C 00 06 spoof reply
S 00 02 connection reply
C 00 03 xx xx xx xx 09 login (reliable)
S 00 03 xx xx xx xx 0a login result (reliable)

What is a "spoof check" and a "spoof reply". I saw the official definition is "Sync Request" and "Sync Reply". Do you mean the same?
CypherJF wrote:

Did Qndre say Snrrrub space is open-source? If so, is there a site with it on there for download?

Yes. Snrrubspace is open-source. I've attached the source to one thread of this client. I don't know the original URL of the site I haven't got it any more.

So I hope now there are no misconceptions any more so we can continue talking about technical stuff.
Mr Ekted - Wed Feb 18, 2004 9:51 am
Post subject:
CypherJF wrote:
Does it essentially come down to, people do not have < insert time/patience/money/resources/any/both/etc > to complete it?


The word you are looking for is skill. Seriously, it takes a huge amount of skill to design all the aspects of an online client/server. You have to understand networking, timing, graphics, sound, user interface, encryption, checksum/crc, complex data structures. As much as I pick on JeffP for some of the quirks in the original SS, he got the job done.
Mr Ekted - Wed Feb 18, 2004 10:01 am
Post subject:
Qndre wrote:
Already tried this out on my own. Server doesn't accept a nul-key (00 00 00 00), but a full-key (FF FF FF FF).


Most servers are setup to require encryption. You are to alowed to connect if you request encryption off.

Qndre wrote:
What is a "spoof check" and a "spoof reply". I saw the official definition is "Sync Request" and "Sync Reply". Do you mean the same?


It is possible to access sockets at the raw level and create your own IP header. Doing this you can put in any IP address you want in the from field. Since the reply from the server is comletely expected, you can wait a bit and send another forged login packet. If you did this for thousands of IP addresses, the server would think thousands of players were legitimately trying to login and start to setup the structures to accommodate this. It would also block real people from logging in for some time. Instead the server replies to an 00 01 by sending an 00 05 packet with a secret hash. The client must reply with an 00 06 and the same hash in order to continue the login process. Since the 00 05 will be sent to the forged IP, the "hacker" will never see the reply, and will not be able to issue the correct response. The secret hash is used so the server doesn't have to remember anything about the connection attempt. It sends the 00 05 and forgets about it. When the 00 06 comes back, it can re-compute what the hash would have been to verify the packets are coming from the specified IP.

When the client sends an 00 05, this is a sync packet. You will find some of the SS packets have different meanings (and structure) depending on which direction they are going. It would not be my choice to design a protocol this way.
Qndre - Wed Feb 18, 2004 11:30 am
Post subject:
Mr Ekted wrote:
[..]
When the client sends an 00 05, this is a sync packet. You will find some of the SS packets have different meanings (and structure) depending on which direction they are going. It would not be my choice to design a protocol this way.

But S2C (server to client) 00 05 is also sync packet. Look at the packet list of ExplodyThingy and please correct me if I'm wrong. biggrin.gif
And I've got another question.
If you see this in the packetlist:
Quote:

0x0005 Core 0x4450E2 Sync Request

What is the underlined hex-value?
Mr Ekted - Wed Feb 18, 2004 11:35 am
Post subject:
Qndre wrote:
But S2C (server to client) 00 05 is also sync packet. Look at the packet list of ExplodyThingy and please correct me if I'm wrong.


It's an incorrect comment.

Qndre wrote:
0x0005 Core 0x4450E2 Sync Request


0x4450E2 looks like the in-memory address of the packet handler in the server. This is provided so you can debug or disassemble the server to see what it does when it receives this packet.
Qndre - Wed Feb 18, 2004 11:43 am
Post subject:
Mr Ekted wrote:

It's an incorrect comment.

In what should I believe? I see this on the packet list but you give me different information. biggrin.gif
So if I've worked with the packetlist till now then I can't do anything because the 0x0005 is the second packet which is exchanged between Server and Client. Please tell me the correct parameters of the 0x0005 core packet. Maybe I can solve my problems this way.

Thanks, Qndre
Mr Ekted - Wed Feb 18, 2004 12:08 pm
Post subject:
S2C spoof packet is:

Code: Show/Hide
00 05 rr rr rr rr


Client should reply:

Code: Show/Hide
00 06 rr rr rr rr cc cc cc cc


where cccccccc is client time. I assume you know that all fields in SS protocol are Intel order.
Qndre - Wed Feb 18, 2004 12:42 pm
Post subject:
Mr Ekted wrote:
S2C spoof packet is:

Code: Show/Hide
00 05 rr rr rr rr


Client should reply:

Code: Show/Hide
00 06 rr rr rr rr cc cc cc cc


where cccccccc is client time. I assume you know that all fields in SS protocol are Intel order.

OK. Thanks for that information. But what does "Intel order" mean?
Dr Brain - Wed Feb 18, 2004 12:55 pm
Post subject:
Someone lock this thread NOW.
Mr Ekted - Wed Feb 18, 2004 12:57 pm
Post subject:
Qndre wrote:
But what does "Intel order" mean?


Ok I guess you didn't know. I thought you had done networking before?

Intel order, or little endian, means the least significant byte comes first. So the 32-bit value of 0x00000001 would be stored in a packet as 01 00 00 00 which matches the way it is stored in memoryon Intel machines. This means you can define your packets as structures (packed of course), just fill in the structure and send. On big endian computers, such as Motorola, if you wanted to send the same packet in the same way, you would have to speficially byte swap all 16- and 32-bit values to put them into Intel order. Of course, if the protocol were defined the other way, then you'd have to do swaps for Intel, but since SS is a Windows game (so far) it was an easy choice.
Mr Ekted - Wed Feb 18, 2004 1:01 pm
Post subject:
Dr Brain wrote:
Someone lock this thread NOW.


Heh. Well it seems to have gone from a discussion of SS clients to a discussion of Programing 101. So maybe a new thread is in order.
Qndre - Wed Feb 18, 2004 1:03 pm
Post subject:
Dr Brain wrote:
Someone lock this thread NOW.

Mine GO BOOM wrote:

I personally wouldn't stop posting because of other people's responces as long as you still have the chance to learn, but I still feel my first statement is true. The way you are attempting to go about this is impractical.

Qndre - Wed Feb 18, 2004 1:10 pm
Post subject:
Mr Ekted wrote:
[..]



Ok I guess you didn't know. I thought you had done networking before?

Intel order, or little endian, means the least significant byte comes first. So the 32-bit value of 0x00000001 would be stored in a packet as 01 00 00 00 which matches the way it is stored in memoryon Intel machines. This means you can define your packets as structures (packed of course), just fill in the structure and send. On big endian computers, such as Motorola, if you wanted to send the same packet in the same way, you would have to speficially byte swap all 16- and 32-bit values to put them into Intel order. Of course, if the protocol were defined the other way, then you'd have to do swaps for Intel, but since SS is a Windows game (so far) it was an easy choice.

Oh. So this means I have to send LSB first and MSB last? Oh. That's new to me. So this means if I want to send 00 00 00 01 then I actually have to send 01 00 00 00 so that the data packet is in Intel order? icon_sad.gif But my software now sends
Code: Show/Hide
chr(0) + chr(0) + chr(0) + chr(1)

and server responds. How is that possible? Do I have to change the order now or not?
Mr Ekted - Wed Feb 18, 2004 1:26 pm
Post subject:
First of all, building up packets a byte at a time is silly. But that another issue.

The server will respond to valid packets. So it depends if sending 00 00 00 01 and 01 00 00 00 are both valid things to send. And this depends on which packet and which value in that packet. Everything I have posted about packet contents that been in the order they are expected. For example if you choose to connect with a key of 0xff123456 (key must have upper bit = 1) then the packet would look like:

Code: Show/Hide
00 01 56 34 12 ff 01 00

Qndre - Wed Feb 18, 2004 2:28 pm
Post subject:
Mr Ekted wrote:
First of all, building up packets a byte at a time is silly. But that another issue.

The server will respond to valid packets. So it depends if sending 00 00 00 01 and 01 00 00 00 are both valid things to send. And this depends on which packet and which value in that packet. Everything I have posted about packet contents that been in the order they are expected. For example if you choose to connect with a key of 0xff123456 (key must have upper bit = 1) then the packet would look like:

Code: Show/Hide
00 01 56 34 12 ff 01 00

OK so every parameter is written little endian but not the headers and the order of the parameter is like the server expects it. Then I know what I've made wrong. Thank you very much. I'll try it out the way you explained.
nintendo64 - Wed Feb 18, 2004 4:00 pm
Post subject:
Ekted, before this threads becomes truly Programming 101, Qndre must take English Reading and Comprehension 101. He keeps asking the same Questions, and even thought i pointed that, he completely missed the point.

Also Qndre now, do you understand that cracking CTM encryption without any knowledge to do so (you practically just admitted it) won't get you anywhere? (i guess CTM's encryption isn't very very very very very simple anymore).

-nintendo64
Mr Ekted - Wed Feb 18, 2004 4:15 pm
Post subject:
Qndre wrote:
OK so every parameter is written little endian but not the headers and the order of the parameter is like the server expects it. Then I know what I've made wrong. Thank you very much. I'll try it out the way you explained.


Including the headers. But everything in the headers is 1 byte except the sequence number in the reliability header, which is 4. In C you just define each packet as a structure, write the values you want for each field, encrypt, and transmit. You don't heven have to think about Intel order, because that's how it's stored automatically. This would be true in BASIC if you used packed structures as well.

I don't know Snrrrub code, but I know MERV code picks apart packets a field at a time in the handler:

Code: Show/Hide
BYTE mode = getByte(msg, 1);
Uint16 width = getShort(msg, 2);
Uint16 height = getShort(msg, 4);
Uint32 duration = getLong(msg, 6);


This is a totally disgusting way to do it. It is likely carried over from the original VB code. No one who is competent in C would do it this way from the beginning.
ExplodyThingy - Wed Feb 18, 2004 5:34 pm
Post subject:
I agree its time to split this thread off just after Qndre's massive reply with all those quotes and responses. Would be better for our sanity.

Ekted would rather load the whole thing into a struct and access each field as needed? I have my bot do it this way simply because I found it to be easier when first starting out, and due to laziness of not wanting to update my sample sources.

Poor description my ass. Its a packet title I gave it or was given by others. The core packets are bi-directional. ARe you saying there are no sync requests performed in both directions?
CypherJF - Wed Feb 18, 2004 5:35 pm
Post subject:
Nintendo, don't take this the wrong way, but material here I would hardly call "programming 101".. If it was, it'd be taught in every programming course. I mean even at Penn State, C++ for CS1/2 this material is never covered. What course teaches packets/hex/etc... none that I know of.

I know this will come to be useful someday, that someone might come back and read. This is why I have not locked this topic.

I ask respectfully, that you stop calling this "programming 101".

pfft... MGB, post #199 title is really gay lol... icon_smile.gif
Mine GO BOOM - Wed Feb 18, 2004 6:07 pm
Post subject:
CypherJF wrote:
I mean even at Penn State

Ohh.. State College?
Mr Ekted - Wed Feb 18, 2004 6:16 pm
Post subject:
ExplodyThingy wrote:
Poor description my ass. Its a packet title I gave it or was given by others. The core packets are bi-directional. ARe you saying there are no sync requests performed in both directions?


The 00 05 packet that the server sends after you send 00 01 may have the same structure and packet id as a sync packet, but it is used for another purpose. That is my point. So calling the packet a sync packet is confusing to someone trying to understand the connection protocol.
Jason - Wed Feb 18, 2004 6:19 pm
Post subject:
Yeah, this certainly isn't programming 101. If they started right in with this kind of stuff when I started at RIT, I would have shit my pants and gone running home to my mommy. :/
ExplodyThingy - Wed Feb 18, 2004 6:37 pm
Post subject:
Ah, screw it. Im not changing that...

This is definately far beyond the scope of programming 101. Im taking a Honors CS class now where they teach Java, and 'char', short, byte, long, arent even on the AP exam. So this has got to be programming 301 or 401, or network programming 101.
Mr Ekted - Wed Feb 18, 2004 7:08 pm
Post subject:
Programming is something I am very passionate about. Could you tell? I took loads of classes in college, worked for 20 years in the field doing some very complex stuff. I've worked with people with the full spectrum of skills. The one thing that the people with average and lower skill shared was a complete lack of understanding of the basics. And when I thought back to school, I realized that [what I call] "the basics" is never taught.

Students are thrown into the language of the day, and are expected to start spewing crappy code from day one. The gifted students figure out the basics as they go, but 90% do not. When I see people talking at a high level about complex topics when they have no foundation, it just pisses me off. Not really at them specifically, but at the educational system that created them.

What are the basics?

- Complete understanding of code, data, stack, heap. Not defining the terms. Understanding them.
- Understanding of memory usage, layout, access, and interpretation.
- Decent understanding of some kind of assembly. Debugging.
- Number bases, precision.
- Data organization (size vs speed, etc).

You should not be allowed to start programming until you have acquired these skills. And if you are unable, then maybe accounting is more up your alley.

</rant>
ExplodyThingy - Wed Feb 18, 2004 7:48 pm
Post subject:
Thank you for saying it. Qndre reminds me of me some time ago. New to the scene, almost no understanding of what was going on, but experience. That said, I believe Qndre, like me, has the potential to do this thing, but is missing the tools and skills. Hes very inquisitive, if you havent noticed, and is sticking with it despite the doubts people have shown him.

You stated my ideas about classes exactly. I always believed they should begin with machine layout, nuts and bolts type of deal. Just so you know, there are people on both ends of the programming spectrum who have those ideas, one of the CS teachers at my school for example.

Before I begin to sound like an arrogant know-it-all, Id like to point out Im a product of said system. But I am working on my flaws.
CypherJF - Wed Feb 18, 2004 7:56 pm
Post subject:
I really don't know how to respond to that... (this is not meant to be a 'smart' remark or in anyway offensive to anyone...)

But... As a student, I'm getting tired of learning "bits 'n parts" of languages (Perl, PHP, C++, VB, Java). For example: PSU does 1 year of C++, never got into anything more complex than binary tree's. I mean, comon'. (they don't offer anything higher than CS2 course, at least at the campus I was at...) which leaves me to learning on my own {ill talk later about that }...

I've scored A's in my programming courses, they're very easy -- which is really sad when I see 80/90% of the class drop out or fail. (mind you, these are people who are planning on becoming 'computer engineers').

But there again Mr Ekted, as you said, as you've looked back you noticed that they never taught these 'basics'. So what can a person like myself do, if they're not even teaching these things?

So I go attempt to try things out, learn on my own, attempt to ask questions to people such as people on the IRC network (and forums), people just respond with 'smart' and 'sourcastic' remarks... What I find 'funny' is that they act as if they weren't a newb once also... I recognize and understand they have spent their fair share of time in the area, but that is why at least I go and attempt things, try em out first and whatnot then ask... but it just becomes irritating trying to learn it on your own, when you just get smart comments back... Thats why if someone asks me for C++ help, I give it to em. I try to at least give them credit for trying to learn something...

But I can see the situation where people try to build a dam, before learning engineering skills.. okay maybe a bad example, but I think you guys get the point...

So all-in-all.. thats yeah my "rant" icon_smile.gif lol..
Mr Ekted - Wed Feb 18, 2004 8:16 pm
Post subject:
Here's a great example. Give this to "experienced" people with no basics and they will get the wrong answer, or won't even understand how to find the answer.

You compile and run the following code under 32-bit Windows on an Intel box. What is the output?

Code: Show/Hide
void main ()
{
unsigned short a;
unsigned long  b[2];

b[0] = 1;
b[1] = 2;
a = *((unsigned short *)((char *)b + 3));
printf("%x", a);
}


Even if you don't understand how or why now, you should be learning how and why. This problem should consume your thoughts until it becomes second nature.
CypherJF - Thu Feb 19, 2004 12:42 am
Post subject:
not to change the subject --

Does anyone know what all Rodvik helped implement in SS? How about Jerod Bennett (VIE Creds 1.35)

And does anyone know what projects their working on now?
Mr Ekted - Thu Feb 19, 2004 1:08 am
Post subject:
I was always under the impression JeffP did all the coding. Didn't many of the VIE crew go to Sony?
CypherJF - Thu Feb 19, 2004 1:11 am
Post subject:
I thought JeffP did the coding, but i looked back throughout the subspace new's file from VIE, and they had many entries from Rod, saying what had been changed, and implemented etc... meh who knows :/

And I'm not sure, I thought the guys had worked together pre-Sony bought Infantry, then Im not sure what all happened... weird.. o well thanks

edit:

went through some old infantry news -- and stumbled across a link to www.infantry-sector.com where in a subpage had "Much of the prevailing content was written and developed in conjunction for Infantry by Rod Humble, former Infantry Producer" ... so I'm assuming Rod worked w/ production of software?
Qndre - Thu Feb 19, 2004 6:46 am
Post subject:
Quote:

Why do you say C looks like junk to you when you can read that? It's almost exactly C.

I haven't only read that application I posted. I've also written it.
You can see it here:
http://forums.minegoboom.com/viewtopic.php?p=15572#15572
Do you still think I'd be a noob?
Qndre - Thu Feb 19, 2004 7:39 am
Post subject:
Mr Ekted wrote:
Here's a great example. Give this to "experienced" people with no basics and they will get the wrong answer, or won't even understand how to find the answer.

You compile and run the following code under 32-bit Windows on an Intel box. What is the output?

Even if you don't understand how or why now, you should be learning how and why. This problem should consume your thoughts until it becomes second nature.

The output is 200

Why doesn't this code work:

Code: Show/Hide

#include "stdafx.h"
#include "timer.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

BEGIN_MESSAGE_MAP(CTimerApp, CWinApp)

END_MESSAGE_MAP()

CTimerApp::CTimerApp()
{

}

// <--- Self-written code begins here ---
DWORD nmyinput = 0;

extern "C" __declspec(dllexport)
void respondtogettimer(nmyinput)
{
DWORD dwstart = gettickcount();
return dwstart;
}
// <--- Self-written code ends here ---

CTimerApp theApp;

Compiler gives:
Quote:

error C2448: '<unknown>'

Mr Ekted - Thu Feb 19, 2004 8:53 am
Post subject:
Qndre wrote:
The output is 200


I didn't want you to run it. I wanted you to figure it out in your head. Do you know why the output is 0x200?
Mr Ekted - Thu Feb 19, 2004 8:57 am
Post subject:
Qndre wrote:
error C2448: '<unknown>'


What line is the error on? It doesn't look like you pasted the entire error text.

Why are you trying to make a DLL simple to call GetTickCount() for you? Why not call GetTickCount() inside your VB directly? And why for the love of god are you using MFC?
Qndre - Thu Feb 19, 2004 9:06 am
Post subject:
Mr Ekted wrote:
[..]
Why not call GetTickCount() inside your VB directly? And why for the love of god are you using MFC?

I already tried it out without MFC but made errors in the source. So I looked into my C++ book and there was the solution: "Write an MFC dll". I also didn't know why but first I've written a DLL without MFC. But that code also didn't work:
Code: Show/Hide

//Tick counter export module

#include "windows.h"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                )
{
    return TRUE;
}

extern "C" __declspec(dllexport);
{
   DWORD dwstart = gettickcount();
   return dwstart;
}

Why don't call gettickcount() in the Basic application? Because Basic doesn't support that function. Even if I declare it.
At example-apps they do it like this:
Code: Show/Hide

Private Declare Function GetTickCount Lib "Kernel32" () As Long

But that doesn't work because "GetTickCount" isn't included in Kernel32.
Already tried it with "User" instead of "Kernel32" but also doesn't work.
_
About your example code:
Quote:
Do you know why the output is 0x200?

No. Not experienced enough.
Mr Ekted - Thu Feb 19, 2004 9:59 am
Post subject:
Qndre wrote:
But that doesn't work because "GetTickCount" isn't included in Kernel32.
Already tried it with "User" instead of "Kernel32" but also doesn't work.
No. Not experienced enough.


Of course it's in kernel32. Your exact declaration shows up all over the web in VB source code. You are doing something wrong.

Qndre wrote:
No. Not experienced enough.


If you learn why the output is 0x200, you will be taking your first step on the road to greatness.
Qndre - Thu Feb 19, 2004 10:05 am
Post subject:
Mr Ekted wrote:

You are doing something wrong.

That's sure. But what? biggrin.gif *debug*
_
I'll try it... Give me some time. I'm sure YOU know. And I'm sure MGB also knows.
Mr Ekted - Thu Feb 19, 2004 10:27 am
Post subject:
I don't know VB that well. I'm sure someone here uses it enough that they can help you with this specific problem.

When you hit a problem like this, it's important that you stop and try to understand what's wrong. If you constantly try something else, you will not learn. Once you get over the GetTickCount() problem, you will be able to use Win32 calls more confidently.

Note that using MFC is similar to using VB. The smallest things result in huge files. An MFC DLL that does the same thing as a raw Win32 DLL will be 10x larger.
Dustpuppy - Thu Feb 19, 2004 11:37 am
Post subject:
@ Qndre:
You've said it doesn't work, but why not? What error do you get? The declaration you gave is fine, have you even tried it?

@Ekted:
Here's my attempt at understanding your little program. Forgive me if I'm being stupid, but I'm just a first year CS student tongue.gif

.
.
.
.
Spoiler space icon_smile.gif
.
.
.
.
.
b is an array of 2 longs, which is 2 sets of 4 bytes.
The first long is set to 1 and the 2nd is set to 2, which would give:

0000 0000 0000 0010 | 0000 0000 0000 0001

in binary. (Note that b[1] is on the right since that's how it will be read as a char*)

a is set to ((char *)b + 3)). So, the pointer will be incremented by 3 bytes first:

Code: Show/Hide

0000 0000|0000 0010|0000 0000|0000 0001
         ^ 3 bytes ^ 2 bytes ^ 1 byte


So a will be given the value:
0000 0010 0000 0000 0000 0001

But since a is a short and can only hold 2 bytes, the last byte will be cut off, giving a value of:

0000 0010 0000 0000

Which is 512, or 200 in hexadecimal icon_smile.gif
Qndre - Thu Feb 19, 2004 11:40 am
Post subject:
Mr Ekted wrote:

When you hit a problem like this, it's important that you stop and try to understand what's wrong. If you constantly try something else, you will not learn. Once you get over the GetTickCount() problem, you will be able to use Win32 calls more confidently.

Note that using MFC is similar to using VB. The smallest things result in huge files. An MFC DLL that does the same thing as a raw Win32 DLL will be 10x larger.

Yes. I don't like MFC applications because they are slower than RAW-C and they support automation. That's something that I really DON'T like. I don't like it if a program does something that I haven't told to do. biggrin.gif That's why I set EVERY PROPERTY I see even in HTML because then the system can't set what it wants.
In one of my projects I had a problem and it took months just to find out what's wrong and then some weeks to correct. But I'm glad I've solved the problem. Sometimes there are instant-solutions for a problem. I also don't like them because then I don't know what I am doing. I like it to figure out solutions on my own.
That's why I started this project. I wanted to get experienced in application devellopment.
And I wanted to get a bit well-known because I'd be the first who cracked C38 encryption. biggrin.gif
But I'll have to hurry up a bit because maybe someone else is also trying. biggrin.gif
Dustpuppy wrote:

You've said it doesn't work, but why not? What error do you get? The declaration you gave is fine, have you even tried it?

I hope you mean the "gettickcount()"-thing. Tried it again. Now it worked. I guess it was only a typing mistake. biggrin.gif
Even the best programmers do something like this. biggrin.gif
_
But one question is still there: The "gettickcount()"-function is a kernel call and the kernel is an application running on the computer, executed by the CPU. So if my program can't be executed fast enough to count 100ths of seconds why can the kernel count MILLISECONDS? Is it a hardware solution (kernel reads the CMOS timer there are milliseconds) or is it really software that the kernel adds 1 to a variable every millisecond? If yes, how is that possible?
Mr Ekted - Thu Feb 19, 2004 2:35 pm
Post subject:
The kernel has access to all the hardware on the system. It can do whatever it wants. Applications have to access that "virtual" hardware through the kernel so that the system is protected, and things are shared as nicely as possible.

The granularity of GetTickCount() depends on your OS. You should not write apps that count on it being any finer than 10ms. This is sufficient for real-time games, and is what SS/Cont use for internal "ticks". You should be able to call GetTickCount() many thousands of time per second (as a test), but you will usually see it advance in increments greater than 1, like:

10000000
10000000
10000000
10000000
10000000
10000000
10000010
10000010
10000010
10000010
10000010

How can you count time in your app all by itself without access to some kind of clock? That's the whole point. You need to ask the system what the time is.

As far as Cont 0.38 encryption: if you spent the next 4 years becoming an elite hacker, you might be able to then crack it in a month. I don't say this to insult you. I say it so you won't waste your time (and ours) trying to do something that is way over your head.
Dr Brain - Thu Feb 19, 2004 4:49 pm
Post subject:
Mr Ekted wrote:

How can you count time in your app all by itself without access to some kind of clock? That's the whole point. You need to ask the system what the time is.


Create a thread with

Code: Show/Hide

long myTime;
while (true)
{
    myTime++;
}


icon_wink.gif. Not that something like that would work remotly as well as getting the time from the OS.
Mr Ekted - Thu Feb 19, 2004 5:20 pm
Post subject:
That would be a thread that would use 100% CPU, and only be a counter. There would be no correlation between the value and real time.
Cyan~Fire - Thu Feb 19, 2004 6:47 pm
Post subject:
Yeah.

And BTW, Ekted, you've been referring to VB, while I think Qndre is programming in just plain BASIC. He hasn't said anything about VB before.

And you still didn't answer my question, Qndre. Why do you say you can't read C when you can write that?
Mr Ekted - Thu Feb 19, 2004 7:30 pm
Post subject:
You are right. I assumed VB. Is there a compiler for BASIC that actually builds decently small and efficient EXE's? It's gotten way better over the years, but C is still the best choice for apps other than writing pure ASM.
Qndre - Fri Feb 20, 2004 8:14 am
Post subject:
Mr Ekted wrote:
As far as Cont 0.38 encryption: if you spent the next 4 years becoming an elite hacker, you might be able to then crack it in a month. I don't say this to insult you. I say it so you won't waste your time (and ours) trying to do something that is way over your head.

You've told me that CTM generates a hard-to-guess keystream.

icon_exclaim.gif I've got a solution icon_exclaim.gif

You have a key:

FF AE 64 FF

And you have a continous keystream between client and server. At example:

Code: Show/Hide

57 47 A5 86 A8 59 2A 36 48 56 AA 39 8A 57 76 A4 35 A8 6A 23 48 97 A5 24 45 6A 3A A2 8A 55 A2 A5 98 7A 46 5A A8 3A A2 65 AA 98 2A 63 45 6A 43 A9 85 ...


This was just an example, not a valid keystream.
And this keystream (not the key itself) is just simple-xorred with the data. Please don't say "that's not true" because I KNOW IT FOR SURE.

I guess that I can't use ANY keystream (at example FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ...) for encryption but any key. But the keystream has to be something specific depending on what key you've set in the 00 01 core packet (I guess). I'll try it out. If I can take ANY keystream then it's very very simple. If I can't take any keystream then I'll have to figure out how to generate a valid one (or just steal ONE of the keystreams out of CTM by figuring out the I/O). The original CTM client generates this keystream and encrypts its packet with it. So that should be the solution. I capture ONE of the keystreams the CTM client uses (after some time it becomes periodic because every encryption does) and I look at the 00 01 core packet. Then my application uses EXACT THIS key because of the other keys I don't know the keystream. That's the solution.
Mr Ekted - Fri Feb 20, 2004 8:51 am
Post subject:
The keystream is not transmitted between the client and server, just the key. The code to generate a keystream from a key is over 1000 lines of C. It is not "easy". And it is also pointless to try for political reasons.

Move on to something useful.
Qndre - Fri Feb 20, 2004 9:04 am
Post subject:
Mr Ekted wrote:
The keystream is not transmitted between the client and server, just the key. The code to generate a keystream from a key is over 1000 lines of C. It is not "easy". And it is also pointless to try for political reasons.

Move on to something useful.

No it's not transmitted between the client and the server but the client generates the keystream and encrypts the data with it. And the key itself is transferred. And with the key you can generate a new keystream out of the key. Why should it me pointless for POLITICAL reasons??? Don't understand...
_
I first want to write a SUBSPACE client so it's necessary to figure this encryption out before trying to crack CTM. I'll make the software VIP and try to recieve simple commands through private message, then I'll try to generate simple stats (who owns which flags, who died, etc. - already planned the stats-page). Finally I'll make the bot spectate the game and send the rendered areas (and maybe a radar view) to ppl who are spectating using webbrowser.
_
CTM encryption will be the VERY LAST STEP!
_
Only one question open: If I use VIE encryption - will I still be able to recieve LVZ?
_
And another question... How does the password-encryption work? I only see something like 56A7A25465DB9CEAE682ADF3B7C59AA8EDF4B6A0EC8B345623FBA8B545A89FF34A586ACB. (just an example - no real value).
Mr Ekted - Fri Feb 20, 2004 11:56 am
Post subject:
Qndre wrote:
Why should it me pointless for POLITICAL reasons??? Don't understand...


If you somehow cracked it, a new encryption algorithm would be created in a day, and all servers would require it, rendering your app useless. So what's the point?

You seem to think that you are capable of doing this when you haven't even been able to connect to a server yet. Take the number of days it takes you to get to that point, multiply by 100, and that's how long it will take you to crack the encryption.
Mr Ekted - Fri Feb 20, 2004 11:58 am
Post subject:
Password encryption is something custom I did to prevent people from simply seeing a password raw on someone else's screen and being able to remember it. I'm not going to explain how that works either. icon_smile.gif
Qndre - Fri Feb 20, 2004 1:33 pm
Post subject:
Mr Ekted wrote:

You seem to think that you are capable of doing this when you haven't even been able to connect to a server yet. Take the number of days it takes you to get to that point, multiply by 100, and that's how long it will take you to crack the encryption.

So you mean it would take 300-400 days? That's not too much. I've even done projects some years after starting them.
Mr Ekted wrote:

Password encryption is something custom I did to prevent people from simply seeing a password raw on someone else's screen and being able to remember it.

But I don't have to transmit the ENCRYPTED password to the server but the plain text (only with CTM encryption), it's only stored encrypted in the file, right?
_
If not: How to transmit passwords in VIE encryption then?
Anonymous - Fri Feb 20, 2004 1:53 pm
Post subject:
Qndre wrote:

So you mean it would take 300-400 days? That's not too much. I've even done projects some years after starting them.


And then on the 401st day your work would be worthless. Get it into your thick head that it's pointlesss to crack it.
Qndre - Fri Feb 20, 2004 1:59 pm
Post subject:
Anonymous wrote:
[..]
And then on the 401st day your work would be worthless.

That's not correct because the encryption itself doesn't change (that would be too much work). Only the key changes. And if I've got the TRUE ALGO then I can implement every key I want.
_
Found out something new. The Subspace (not CTM) keystream is 4160 bits long. CTM is about 272629760 bits long (10400000 in hex value). But I don't know it for sure ...
So if the keystream is this long, then trying to crack it using brute-force doesn't work.
_
I'll write my client for VIE encryption first (including standard lvz and my own lvz) and then making it generate some stats at my own (allow VIE client) zone.
Mr Ekted - Fri Feb 20, 2004 2:17 pm
Post subject:
Qndre wrote:
That's not correct because the encryption itself doesn't change (that would be too much work). Only the key changes. And if I've got the TRUE ALGO then I can implement every key I want.


You are going to make me start yelling at you again.

If Cont encryption is cracked, PriitK will change the algorithm, and re-release Cont and subgame2 on the same day. Get it this time?
Qndre - Fri Feb 20, 2004 2:20 pm
Post subject:
Mr Ekted wrote:
[..]
If Cont encryption is cracked, PriitK will change the algorithm, and re-release Cont and subgame2 on the same day. Get it this time?

1. You said the encryption would be about 1,000 lines in C. Re-writing this would take months.
2. Why should everyone use the new subgame2-server instead of the old? Because encryption is known and someone could be cheating? And what if I make a deal with some zones? They let my software in and I make stats of them and let everyone without CTM spectate. I wouldn't say "no". Would you do?
_
And why do you start talking about this F****** CTM ENCRYPTION AGAIN AND AGAIN??
_
I'll say it the last time:
I WANT TO WRITE THE CLIENT FOR VIE *shout*
I ONLY WANTED TO SAY THAT IT IS POSSIBLE TO CRACK IT NOT THAT I WOULD DO IT IMMEDIATELY
QUOTES:
Quote:

I'll write my client for VIE encryption first (including standard lvz and my own lvz) and then making it generate some stats at my own (allow VIE client) zone.

Quote:

How to transmit passwords in VIE encryption?

Quote:

I want to write a SUBSPACE client so it's necessary to figure this encryption out before trying to crack CTM.

Quote:

It doesn't matter if I write a Continuum or a Subspace client. It's nearly the same.

Quote:

I've got some questions about VIE encryption

And even a reply of MGB which says this.
Mine GO BOOM wrote:

Using that encryption method instead of the VIE encryption only changes VERY little of the actually packets sent between the clients.


...
Sorry if that was a bit impolite but if no one gets it... biggrin.gif
Mr Ekted - Fri Feb 20, 2004 2:42 pm
Post subject:
Qndre wrote:
1. You said the encryption would be about 1,000 lines in C. Re-writing this would take months.


Re-writing would take minutes.

Qndre wrote:
2. Why should everyone use the new subgame2-server instead of the old? Because encryption is known and someone could be cheating? And what if I make a deal with some zones? They let my software in and I make stats of them and let everyone without CTM spectate. I wouldn't say "no". Would you do?


I will tell you now that if Cont is cracked, every zone on SSC biller will used the new subgame and will require the new Cont. Of course anyone is free to run another zone as they wish if they want to live with constant cheaters.

Qndre wrote:
Sorry if that was a bit impolite but if no one gets it.


We get that you make wild statements. We get that you are very inexperienced. We get that you have shown nothing for all your claims. It's been many days since you showed up here, and you are still asking questions that would only be asked by people who are incapable of actually doing anything.
Qndre - Fri Feb 20, 2004 2:57 pm
Post subject:
Mr Ekted wrote:
[..]
We get that you are very inexperienced. We get that you have shown nothing for all your claims. It's been many days since you showed up here, and you are still asking questions that would only be asked by people who are incapable of actually doing anything.

I'm not incapable of doing anything. I'm not a newbie. I'm not inexperienced. I'm interested in application development for about 10 years. No, I am absolutely NO elite programmer but have I ever said that? But I've said "I want to write it for VIE encryption" about five times and you didn't get it. Sorry. Your first postings were very useful but now... I guess I'll have to figure this out completely on my own.
CypherJF - Fri Feb 20, 2004 3:03 pm
Post subject:
Mr Ekted, I'm sure you posted this before, but I've seemed to have missed it...

Logging in w/ VIE is selectively allowed depending on subgame's settings... It just tells the server not to send lvz's right? or is there more to it? If it was 'cracked', are there different routines for the server if its a Cont. client, vs a VIE -- I guess I dont see how cheaters could cheat if it's not dependent on VIE or Continuum clients?

Like I said, I prob missed that answer someeeewhere in the last 10 pages... so if you want you can just PM me an answer or just post here... w.e. curious mind
Mine GO BOOM - Fri Feb 20, 2004 3:13 pm
Post subject:
Qndre wrote:
But I've said "I want to write it for VIE encryption" about five times and you didn't get it.

You sometimes freely interchange the word Continuum with VIE when taking about clients and encryption. I did make a point a while ago to try to control this. Though it may not be obvious to you, you do add the word 'ctm' in front of clients and encryptions a lot.

Now that you made your point across that you are putting the cracking of this encyption on the back-burner for a long, long time, I'll try now to sum up what the past 11 pages of requests you have for others. Hopefully, this should be correct.


Am I missing anything? If I got this correct, then we will gladly assist you in your project, as if you create this chat client, which may or may not contain a radar image or a full screen image, this would be a useful project.

If you setup your program correctly, the interaction between your main program and the server should be very modular, in which the main program doesn't care how the connection is made. Then, when servers begin to use ASSS, you can change your connection interface to a new protocol designed for your chat client, in which would be much more reliable and easier to add features to.
Mr Ekted - Fri Feb 20, 2004 3:20 pm
Post subject:
CypherJF wrote:
Logging in w/ VIE is selectively allowed depending on subgame's settings... It just tells the server not to send lvz's right? or is there more to it? If it was 'cracked', are there different routines for the server if its a Cont. client, vs a VIE -- I guess I dont see how cheaters could cheat if it's not dependent on VIE or Continuum clients?


Most zones that allow VIE only allow it in spec, so you can't play. If you could, ppl would still be using Twister to do all sorts of nasty things. The exception to this is that if you login as a sysop, AllowVIE=0 is ignored.

I believe the server sends all packets to all clients regardless of which client it is. Powerbot uses VIE encryption, and it can freely send/recv object packets for example.
Mine GO BOOM - Fri Feb 20, 2004 3:23 pm
Post subject:
CypherJF wrote:
Logging in w/ VIE is selectively allowed depending on subgame's settings... It just tells the server not to send lvz's right? or is there more to it? If it was 'cracked', are there different routines for the server if its a Cont. client, vs a VIE -- I guess I dont see how cheaters could cheat if it's not dependent on VIE or Continuum clients?

If you browse through ASSS's source, it only sends lvz information if it knows the client is Continuum. With the way it was added onto the map-info packet, if it was sent like this to VIE clients, the client would ignore it since the packet is an incorrect size. With ASSS, you could easily add a new packet id for LVZs, in which bots could easily understand.

Cheaters could cheat because Subspace assumes that all clients are valid. Since 99% of all processing of the game is done client side, any client could easily cheat, and the server wouldn't know. If you knew Continuum's encryption method, you could create a packet filter in which you could edit weapons, so L3 bullets would be L1, and L2 prox bombs with 12 shrapnel were only L2 prox bombs. Other users would be hard-pressed to notice slight changes. I know, because I once tried this with VIE encryption to notice if League mods would notice when I was cheating vs when I wasn't, even when I warned them I was doing such things.

Half the time they couldn't tell, and they had a lot of false calls. And *watchdamage wouldn't work, because since you are already editing packets, you can change those damage packets back into the correct levels, and re-add in those fake shrapnel damages.

So, thats why its important to keep the client all users play with different than what programmers have access to. But, as Priit isn't handy anymore, he won't make a bot-encryption, in which it has access to all Continuum things, be it only small things such as LVZ information.

EDIT:
Mr Ekted wrote:
I believe the server sends all packets to all clients regardless of which client it is. Powerbot uses VIE encryption, and it can freely send/recv object packets for example.

The LVZ filenames and checksums for them are not sent under the VIE encryption, as my previous post states. There is one other thing too, forget what it was. Was something like one extra byte flag thrown on the end. Been a while since I was looking at packet logs.
Qndre - Fri Feb 20, 2004 3:48 pm
Post subject:
Mine GO BOOM wrote:

You sometimes freely interchange the word Continuum with VIE when taking about clients and encryption. I did make a point a while ago to try to control this. Though it may not be obvious to you, you do add the word 'ctm' in front of clients and encryptions a lot.

Now that you made your point across that you are putting the cracking of this encyption on the back-burner for a long, long time, I'll try now to sum up what the past 11 pages of requests you have for others. Hopefully, this should be correct.


Needs assistances in setting up a UDP connection with a server.

Needs assistances in using the standard VIE encryption with that connection.

Needs assistance in setting up a database to store this information.

Needs assistance in creating some type of user inferface, be it a website with a live image that updates on a certain interval, or a program users run locally on their machines, in which they could easily store on a USB keychain to bring with them.

Am I missing anything? If I got this correct, then we will gladly assist you in your project, as if you create this chat client, which may or may not contain a radar image or a full screen image, this would be a useful project.

If you setup your program correctly, the interaction between your main program and the server should be very modular, in which the main program doesn't care how the connection is made. Then, when servers begin to use ASSS, you can change your connection interface to a new protocol designed for your chat client, in which would be much more reliable and easier to add features to.


Mine GO BOOM wrote:

If you knew Continuum's encryption method, you could create a packet filter in which you could edit weapons, so L3 bullets would be L1, and L2 prox bombs with 12 shrapnel were only L2 prox bombs.


I. About Nintendo64

1. I freely interchange about Subspace, Continuum, VIE, etc. I know. I mixed it up a bit because some time ago I asked someone in TW about "Continuum" and he said "Continuum?? What's that? I'm playing Subspace!"
2. I don't need assistance in setting up a UDP connection with a server because I know how to form UDP packets and I've already written some network-applications which work correctly. And I never use TCP in my apps because it's slow.
3. I need assistance in using the VIE encryption. That's right.
4. I need assistance in setting up a database? Definitely not because I have some experience with SQL databases.
5. I don't need assistence in creating a user interface. I've created more than 100 test applications. And every single had a full user interface even if I just was trying around a bit.
6. You talk about a "chat client"? Not really. Chat shouldn't be implemented. biggrin.gif
7. You talk about ASSS. The app should work with subgame2.


II. About Mine GO BOOM

Yes. Maybe the second version of my "Specserv" is more a cheat than a tool.


III. Personal question

Maybe I can trick the encryption to implement Force-Continuum-Zones. NOT CRACK it but TRICK it... What does Subgame2 do if I set the version byte to "C38" and the encryption to "VIE"? If it only checks the version byte and then says "let him play - he has CTM" then I've won. And then I tell him that I use "VIE" encryption and start using it. biggrin.gif But I guess this is too easy to work.
Mr Ekted - Fri Feb 20, 2004 4:01 pm
Post subject:
Qndre wrote:
Maybe I can trick the encryption to implement Force-Continuum-Zones. NOT CRACK it but TRICK it... What does Subgame2 do if I set the version byte to "C38" and the encryption to "VIE"? If it only checks the version byte and then says "let him play - he has CTM" then I've won. And then I tell him that I use "VIE" encryption and start using it.


If you tell the server you are Cont, it send packets encrypted with Cont, and expects the same form you. When it decrypts and gets garbage you will be booted.
ExplodyThingy - Fri Feb 20, 2004 4:21 pm
Post subject:
Heres a hint. Do it in BASIC or VB or whatever language you are most familiar with and do it using no encryption, identify yourself as VIE not Cont. The point is, do JUST the basics right now.

Please please please dont fight with us. Accept or reject what you wish, styles, theories, charact judgements, or degrees of dificulty. But with facts, like VIE encryption is public, Cont is not, neither is open sourced, dont fight it.
Qndre - Fri Feb 20, 2004 4:59 pm
Post subject:
ExplodyThingy wrote:
Heres a hint. Do it in BASIC or VB or whatever language you are most familiar with and do it using no encryption, identify yourself as VIE not Cont. The point is, do JUST the basics right now.

Please please please dont fight with us. Accept or reject what you wish, styles, theories, charact judgements, or degrees of dificulty. But with facts, like VIE encryption is public, Cont is not, neither is open sourced, dont fight it.

1. Using no encryption is not possible because subgame2 doesn't take a 0-key.
2. I don't fight with you. I just got different information from other people.
Mr Ekted - Fri Feb 20, 2004 5:00 pm
Post subject:
If you run your own subgame you can set it to allow no encryption.
Qndre - Fri Feb 20, 2004 5:21 pm
Post subject:
My own subgame? It's impossible for me to write an application like that since I'm not a professional programmer. Subgame does almost everything. It has to manage the LVL the LVZ it has to support standard clients like CTM so there is the encryption problem again. It has to simulate the game. It has to generate wireframes. It has to manage connections and generate game data which is sent to the client. It has to recieve game data from other clients. And then it isn't compatible to other zones. That's too hard for me. I won't be able to do that because it has to support standards to allow other clients to connect. That's just IMPOSSIBLE for me. AND this new subgame won't be used by any zone.
Qndre - Fri Feb 20, 2004 5:26 pm
Post subject:
Oh. I have to correct my reply. I think this was a misconception. With "own subgame" you meant I should set up my own zone, right? How can I allow 0-encryption? Never seen an option like this before.
_
But if I have a 0-encryption then I'll still have to return correct checksums, right?
Mr Ekted - Fri Feb 20, 2004 5:26 pm
Post subject:
Um. Download it, and run it on your own computer. Sigh.
Mine GO BOOM - Fri Feb 20, 2004 5:27 pm
Post subject:
Mr Ekted wrote:
If you run your own subgame you can set it to allow no encryption.

Look at what he said. He told you to run your own server, in which you can disable encryption.

And creating a brand new client that does everything Continuum does is harder than a new server. Server only manages connections and forwards packets around. Client deals with user interactions, graphics, physics, etc.
Qndre - Fri Feb 20, 2004 5:29 pm
Post subject:
Mine GO BOOM wrote:
[..]


Look at what he said. He told you to run your own server, in which you can disable encryption.

And creating a brand new client that does everything Continuum does is harder than a new server. Server only manages connections and forwards packets around. Client deals with user interactions, graphics, physics, etc.

I can disable encryption? Never seen an option like that? I can even disable VIE encryption so I can send plain packets? Do I have to return checksums still?
_
EDIT:
These are the only options in relation to CTM and Subspace:

ContinuumOnly = 0
DisableShareware = 0
RegisterKickShareware=0
MaxSharewarePlayers=-1
MaxSharewareTime=90000000
DisableSharewareNames=0
DisableSharewareShips=0
DisableSharewareScores=0
AllowVIEClients=1
ForceContinuumOnly=0
AllowBadMachineId=1

What's the difference between "ContinuumOnly", "AllowVIEClients" and "ForceContinuumOnly"?
What's a "Shareware"-Player??
Cyan~Fire - Fri Feb 20, 2004 6:10 pm
Post subject:
AFAIK, if you're using VIE encryption, you can make a 0 key. Not sure about that though, just wait for someone else to reply. icon_razz.gif
CypherJF - Fri Feb 20, 2004 6:20 pm
Post subject:
Ah yes, he doesn't remember, we used to have to buy Subspace to play, ala 1.34? CD...
Qndre - Fri Feb 20, 2004 6:29 pm
Post subject:
Cyan~Fire wrote:
AFAIK, if you're using VIE encryption, you can make a 0 key. Not sure about that though, just wait for someone else to reply. icon_razz.gif

No. Already tried it out. If I don't set my own zone to Force-Continuum or Continuum-Only and if I enable AllowVIE and then send [[[ 00 01 00 00 00 00 01 00 ]]] packet (0-key) then subgame doesn't respond. If I send [[[ 00 01 FF FF FF FF 01 00 ]]] packet (use-a-key) then subgame responded with a 00 05 core packet. MERVbot is able to connect so CTM encryption is disabled. But VIE-key can't be 00 00 00 00.
Mr Ekted - Fri Feb 20, 2004 6:48 pm
Post subject:
There's a Comms:EncryptMode switch. Not sure what it does. Regardless, make your client a sysop, so there will be fewer things that will get you booted.
ExplodyThingy - Fri Feb 20, 2004 6:50 pm
Post subject:
Ok, dude, subgame supports both continuum and vie encryption. When merv connects with the VIE encryption, it doesnt disable the COnt encryption. If you need, ripoff merv's, logicbot's, explbot's or any of the other open clients out there that have the encryption out there. For you, I recommend you take it out of my core, its far more basic and rudementary, written before I really knew what I was doing. You should be able to figure it out easily.

Im trying to tell you something here: Take it one step at a time. Make abot, make a dummy peice of software that sends only 00 01 and waits for 00 05, then youre good. Put in the encryption at that point. Then add more of the packets needed for login. Then do checksums (which again can be lifted from any of the cores). Then make it enter an arena. Then make it talk. Then make it sustain a connection. Then put in lagout controls. Then webintegrate it as needed.
CypherJF - Fri Feb 20, 2004 8:37 pm
Post subject:
Does Catid's VB Merv version have the ability to login to zones that allow VIE clients? He may want to check that out?
D1st0rt - Fri Feb 20, 2004 9:38 pm
Post subject:
explbot is 1337
ExplodyThingy - Fri Feb 20, 2004 10:47 pm
Post subject:
explbot is junk. Im rewriting it.
Cyan~Fire - Fri Feb 20, 2004 10:53 pm
Post subject:
In regards to my NULL key statement:
Catid (in his protocol doc) wrote:
There are some ways to disable encryption:
Send a KK field of 0. 00 01 00 00 00 00 01 00
The server must respond with a NULL key (no encryption).
Custom SubSpace stacks may ignore this.

Qndre - Sat Feb 21, 2004 4:06 am
Post subject:
Mr Ekted wrote:

Regardless, make your client a sysop, so there will be fewer things that will get you booted.

I can't login yet. I'm far away of that. Now I wrote my client to give a valid timecode, but still have to try it out. If my client hasn't given any login-name yet then he can't be SysOP.
ExplodyThingy wrote:

For you, I recommend you take it out of my core, its far more basic and rudementary, written before I really knew what I was doing. You should be able to figure it out easily.

Thanks. What's the name of your bot? Where can I get the source.
ExplodyThingy wrote:

Im trying to tell you something here: Take it one step at a time. Make abot, make a dummy peice of software that sends only 00 01 and waits for 00 05, then youre good.

Already able to do that. Am I good now? biggrin.gif
Qndre - Sat Feb 21, 2004 4:28 am
Post subject:
I sent a 00 01 FF FF FF FF 01 00 core packet.

Subgame gave me 00 05 core packet.

I responded with:

00 06 00 00 00 0A TT TT TT TT

TT TT TT TT = "Int(gettickcount() / 10)" as a little endian hex value.

Subgame didn't respond.

icon_sad.gif

Seems like the response I gave wasn't correct, was it? I only want to know because then I'll have to search for the problem somewhere else.


Snrrub does it this way:
Code: Show/Hide

// Called when the client needs to send a sync reply to a sync packet (00 06 in response to 00 05)
// DEFAULT BEHAVIOUR: Sends a 00 06 in response
void SSProtocol::OnSendSyncReply(SSPacket & syncPacket)
{
   SSPacket reply(10);

   reply[1] = 0x06;
   reply.SetDword(syncPacket.GetDword(2), 2);
   reply.SetDword(SSGetTime(), 6);

   Send(reply);
}

Mr Ekted - Sat Feb 21, 2004 11:10 am
Post subject:
You must send back the same value in the 0006 packet that you received in the 0005 packet. That's how a spoof check works.
Qndre - Sat Feb 21, 2004 11:17 am
Post subject:
Mr Ekted wrote:
You must send back the same value in the 0006 packet that you received in the 0005 packet. That's how a spoof check works.

Er... If I look at the packetlist then I see that I have to send my ping and my tick counter.
Mr Ekted - Sat Feb 21, 2004 12:16 pm
Post subject:
We've been through this. The comments and names for that packet are incorrect in this case. This is why I have been calling it the spoof packet and not the sync packet. But since you don't listen to me, you keep on doing it wrong. Here's a correct example:

Code: Show/Hide
S  00 05 12 34 56 78
C  00 06 12 34 56 78 tt tt tt tt

Qndre - Sat Feb 21, 2004 12:21 pm
Post subject:
Hey!! Thanks!! It works!! icon_biggrin.gif *jump around*

Thank you very much for your help! I can connect but subgame disconnects me immediatelly (probably because I'm not pinging / sending checksums / sending login packets). OK. Now I have to crack the VIE encryption and then the fun-part begins. Figuring out the game data, write a renderer. Great! Thank you! Without you I had never got to this point.

I WAS SUCCESSFUL! But only because of your help. Thanks.

Qndre

YAHOOOOOOOOOOOO icon_biggrin.gif

Now I can continue develloping the "Metaspace"-client.
Mr Ekted - Sat Feb 21, 2004 12:52 pm
Post subject:
Lol yes. You are about 0.1% of the way there. How many pages of forum posts will it take for you to get the next packet? tongue.gif
Qndre - Sat Feb 21, 2004 1:02 pm
Post subject:
Mr Ekted wrote:
Lol yes. You are about 0.1% of the way there. How many pages of forum posts will it take for you to get the next packet? tongue.gif

Now I'll have to send a login packet. I won't ask anything here if I don't have to. And then the VIE encryption begins. I've got the C-Code of the encryption. I'll take some time to learn C and figure it out on my own.

The code of the encryption:
Code: Show/Hide

#include "SSApplication.h"
#include "SSEncryption.h"
#include "SSPacket.h"
#include "misc.h"

#include <assert.h>

// Default constructor; disables the encryption
SSEncryption::SSEncryption()
{
   m_bEncrypting = false;
   m_uiKey = 0;
   memset(m_auiKeystream, 0, 520);
}

SSEncryption::SSEncryption(sint32 key)
{
   Initialize(key);
}

// Default destructor
SSEncryption::~SSEncryption()
{
}

// Initializes SubSpace encryption. If the encryption key is negative or 0, the encryption is disabled.
// This generates a 520 byte keystream for encryption. Unfortunately SS doesn't reuse the stream for
// packet lengths greater than 520 bytes - it fragments those packets.
void SSEncryption::Initialize(sint32 key)
{
   ClearError();
   assert(key >= 0);

   if(key < 0)
   {
      SetError("[SSEncryption::Initialize] - Invalid key 0x%08X", key);
      return;
   }

   sint32 temp = 0;
   m_uiKey = key;

   for(int cnt = 0; cnt < 520; cnt += 2)      // Each "block" is 2 bytes and the keystream size is 520 bytes
   {
      temp = (uint32)((uint64)((uint64)key * (uint64)0x834E0B5F) >> 48) + (temp >> 31);
      key = ((key % 0x1F31D) * 16807) - (temp * 2836) + 123;
      if((sint32)key < 0)
         key += 0x7FFFFFFF;
      SS_SetWord(m_auiKeystream, (uint16)key, cnt);
   }
   m_bEncrypting = true;
}

void SSEncryption::Shutdown()
{
   m_bEncrypting = false;
   m_uiKey = 0;
}

// Encrypts the packet in-place.
bool SSEncryption::Encrypt(SSPacket & packet)
{
   ClearError();
   if(!m_bEncrypting)                     // Encryption has not been initialized (not an error, it's completely valid)
      return false;

   uint32 packetLen = packet.GetLength();
   assert(packetLen <= 520);
   if(packetLen > 520)
   {
      SetError("[SSEncryption::Encrypt] - Packet length %d is too long for SubSpace encryption.", packetLen);
      return false;
   }

   uint32 startpos = 1;
   uint32 encrypted = m_uiKey;

   if(!packet[0])
      ++startpos;
   for(uint32 cnt = startpos; cnt < packetLen; cnt += 4)
   {
      encrypted ^= SS_GetDword(m_auiKeystream, cnt - startpos) ^ packet.GetDword(cnt);
      packet.SetDword(encrypted, cnt);
   }
   return true;
}

// Decrypts the packet in-place.
bool SSEncryption::Decrypt(SSPacket & packet)
{
   ClearError();

   if(!m_bEncrypting)
      return false;

   uint32 packetLen = packet.GetLength();
   assert(packetLen <= 520);
   if(packetLen > 520)
   {
      SetError("[SSEncryption::Decrypt] - Packet length %d is too long for SubSpace decryption.", packetLen);
      return false;
   }

   uint32 decrypted = m_uiKey;
   uint32 startpos = 1;

// SubSpace does not encrypt the "type" bytes (first two bytes if it's a special packet
// or first byte if it's a regular packet)

   if(!packet[0])
      ++startpos;

   for(uint32 cnt = startpos; cnt < packetLen; cnt += 4)
   {
      uint32 encrypted = packet.GetDword(cnt);

      decrypted ^= SS_GetDword(m_auiKeystream, cnt - startpos) ^ encrypted;
      packet.SetDword(decrypted, cnt);
      decrypted = encrypted;
   }

   return true;
}

uint16 SSEncryption::GetType() const
{
   return 0x0001;      // SS = 1, Ctm .36 = 16, Ctm .37 = 17
}

Mr Ekted - Sat Feb 21, 2004 1:12 pm
Post subject:
You don't have to post source code here that we all have access to unless you have a question about it.
Qndre - Sat Feb 21, 2004 1:16 pm
Post subject:
Mr Ekted wrote:
You don't have to post source code here that we all have access to unless you have a question about it.

OK
ExplodyThingy - Sat Feb 21, 2004 3:54 pm
Post subject:
Thats code from LogicBot isnt it? I ripped mine off from there, but rearranged some variables for simplicity.

CrapBot / ExplBot: http://explody.ssihosting.com/misc/explbot/explbot-src.zip
Qndre - Sun Feb 22, 2004 6:11 am
Post subject:
ExplodyThingy wrote:
Thats code from LogicBot isnt it?

You mean the code I posted? No. It's from Snrrrubspace.
Qndre - Sun Feb 22, 2004 6:42 am
Post subject:
Now I have to generate 09 game packet. 14 bytes aren't known 73+74 and 89-100 (including 100). I'll try to set them all to 0. The two unknown which are set to 444 and 555, 444 and 555 are decimal numbers, not hex-values, right?
Qndre - Sun Feb 22, 2004 7:46 am
Post subject:
Er... The login packet essentially works now but I guess it has to be encrypted with VIE encryption, right? If I log in and send unencrypted 09 core packet then subgame2 gives the following message into the console window:

Code: Show/Hide
Sun Feb 22 13:41:38:  Ext: Player with invalid name tying to enter: _____b__8V_\
_P____5>_2____V____
Sun Feb 22 13:41:38:  WARNING: Connection flood from 192.168.0.3

Smong - Sun Feb 22, 2004 10:06 am
Post subject:
You need to encrypt it with VIE enc. Search the internet for old versions of subgame, you may find one that accepts a null/0 key.
444/555 are in decimal.
I think there is a post somewhere at SFN (ssforum.net) that tells you which 'keys' from the registry are in the login packet. That might what you need to set the unknown values to.
Mr Ekted - Sun Feb 22, 2004 11:02 am
Post subject:
Once you get past the VIE encryption, your next big hurdle will be to properly manage the reliability layer. The SS protocol has the concept of reliable messages that are handled much the same as the TCP stack:

Sender sends packet sequence numbers: 0 1 2 3 4 5...

Receiver may get them as: 0 2 2 3 4 1 2 5 5...

It is imperative that the application level process reliable packets in order with no duplicates. The reliability layer takes care of acknowledging received packets, retrying unacknowledged packets, buffering them until the proper order can be assembled, and sending packets up to the application layer in the proper sequence.

This is a nice little task for someone learning the protocol. icon_smile.gif
Qndre - Sun Feb 22, 2004 2:00 pm
Post subject:
Mr Ekted wrote:
Once you get past the VIE encryption, your next big hurdle will be to properly manage the reliability layer. The SS protocol has the concept of reliable messages that are handled much the same as the TCP stack [..]

Yes. Already heard of that.

About VIE encryption:
I'll have to encrypt everything but the 09 packet header, right? Everything is encrypted except packet headers.
*hrmpf* VIE encryption is so hard to implement ...
ExplodyThingy - Sun Feb 22, 2004 3:13 pm
Post subject:
Vie encryption is easy. Encrypt EVERYTHING afte you setup a key. Set a bool variable to control whether enryption is enabled. In your packe send function, encypt EVERYTHING if encryption is enabled.
Qndre - Sun Feb 22, 2004 4:22 pm
Post subject:
ExplodyThingy wrote:
Vie encryption is easy. Encrypt EVERYTHING afte you setup a key. Set a bool variable to control whether enryption is enabled. In your packe send function, encypt EVERYTHING if encryption is enabled.

Encrypt everything? Simply everything or everything except the packet headers? If I send 09 header unencrypted then server gets what I mean so I just have to encrypt the data which is transmitted in the same packet but is not header (not the first byte if normal, not the first two bytes if core), right?

Quote of an erlier post:

ExplodyThingy wrote:

Everything in the packet is encrypted except the header. The header is the first 1 byte (2 if core type). The packet is encrypted just before is it dispatched to the server, so if youre clustering a packet, nothing is encrypted untill just before its sent.


In that post you say that headers aren't encrypted. Now you say that everything is encrypted...
ExplodyThingy - Sun Feb 22, 2004 4:32 pm
Post subject:
I thought you mean everything except packets of type 09. Just put in the encryption scheme from the various programs out there. They will all take care of encrytion/decryption for you. You dont need to worry about what part is/isnt encrypted. The only thing I know for sure about is that core packets dont encrypt their first byte (the 0x00)
Qndre - Sun Feb 22, 2004 4:37 pm
Post subject:
Headers itself don't seem to be encrypted because if I send a packet then the server knows what it means (understands the header) but doesn't know what its content means (doesn't understand everything following to the header).

As for your BOT-code: You mean I should write a DLL and implement the encryption in it and let my main app call the DLL for encryption? That would offer great possibillities.


Edit:

Found the answer in Snrrub's code. biggrin.gif Subspace encrypts everything except the headers. Maybe I can use Snrrub's encryption module and make a DLL out of it I can call in my main application.
Qndre - Sun Feb 22, 2004 6:09 pm
Post subject:
Qndre wrote:
[..]
Maybe I can use Snrrub's encryption module and make a DLL out of it I can call in my main application.

No. I just can't do it because I can't do C. Already tried to but there were 29 errors in my application which weren't easy to solve (not only forgot a semicolon, etc.)! icon_confused.gif
Cyan~Fire - Sun Feb 22, 2004 8:39 pm
Post subject:
Learn C. You'll get nowhere without it.

And there's also an edit button.
Mr Ekted - Sun Feb 22, 2004 9:15 pm
Post subject:
Agreed. Learn the language first. Make a serious effort to understand the basic syntax and functionality. It will help you way more than just with this project. Feel free to discuss that here as well. L1K
Qndre - Mon Feb 23, 2004 8:30 am
Post subject:
Is there a way to make subgame2 allow nul-keys so I can write a client without encryption first and later write a kind of plugin for it to enhance it to VIE encryption (any maybe later to CTM encryption)?
Dustpuppy - Mon Feb 23, 2004 8:41 am
Post subject:
If you are dead set on using VB, catid's VB merv has encryption code.
Mr Ekted - Mon Feb 23, 2004 9:39 am
Post subject:
It's been 29 days, and so far you've managed to send 2 correct packets...
Qndre - Mon Feb 23, 2004 3:01 pm
Post subject:
CatID's bot has one assembly module. And this module does the encryption. It's only loaded into the VB code:
Code: Show/Hide

Declare Function SSEncrypt Lib "sasme" (SSEncrTable As SStable, StrToEncr As String, ByVal StartPos As Integer) As Long
Declare Function SSDecrypt Lib "sasme" (SSEncrTable As SStable, StrToDecr As String, ByVal StartPos As Integer) As Long

I could just include that assemlby module but I wouldn't learn how encryption works...
Mr Ekted - Mon Feb 23, 2004 3:44 pm
Post subject:
So you are saying if someone doesn't give you the VB source code for something, then you can't do it?
Qndre - Mon Feb 23, 2004 4:40 pm
Post subject:
That's not what I said. I just can't read C/ASM. And the other apps are all in C/ASM. And I can't invent the encryption algo on my own because it has to be VIE's one. Of course I can write client/server apps without anyone's help but if then have to use a specific encryption at example or a specific file format then I can't because I don't know about this encryption or format. I'll create the rest of the client from scratch but not the encryption because I don't understand it. Sorry. The graphics engine, the rest of the network protocol, the user interface, it's all done by me but I can't do the encryption because I don't understand how it works. I've got an assembly code but I can't read it.
Qndre - Mon Feb 23, 2004 5:31 pm
Post subject:
Just told my idea in DSB. The people said it would be a great idea but a bit useless one: (sry if the posting is a bit long but it says much)
Quote:

Qndre> just look into the shanky-server-forum: http://forums.minegoboom.com - posted a thread in "misc user apps" - it's name "spectate-only-client" - that's my project - you can read there about it
Qndre> it could offer physics like friction or gravity or make everyone without the continuum client able to spectate the game
358xz> Are there boys on?
TYpY> eek
Op>Super> woah qndre
Op>Super> i wish u luck
Op>Super> and hope it works
Op>Super> would be ncie
Op>Super> nice

Qndre> yes also if the others say it won't work because encryption has never been cracked
Starpocaly> yeah
Starpocaly> good luck trying to convince priitk

Qndre> thanks
waffy> bah
Op>Super> prickT
358xz> ARE THERE BOYS ON?
Starpocaly> no
Starpocaly> only girls
odd> qndre you need to work on snrrrubspaace
waffy> NO THERE ARE NO MALES ON THIS GAME
Qndre> Snrrubspace - isn't that the linux client?
odd> yeah
358xz> well SHUT-UP?
Nichole> yes
Fook Yu> ow
Op>Super> always moon and jest always not afk good stuff
Werq> wth
Starpocaly> Qndre, yes
Starpocaly> the one that failed i believe
odd> as far as i know it's dead
Nichole> I guess that works
Starpocaly> but the game will constantly change
Starpocaly> and its great fun when u get into it
Qndre> So would you say my project is great or it's trash?
Op>Super> great
Qndre> THX
Qndre> I'll tell this to the ppl who say it's trash.
Werq> Hello super
Op>Super> and still be addicted to shitty 2d continuum
Moon> yes
Starpocaly> it takes ages to get to the level where u cant do anything anymore
Qndre> yes
Qndre> I'm very subspace addicted
Starpocaly> you get bored of everything at
Qndre> just look at www.subspace-addicted.de.vu that's my subspace fanpage
odd> because once you add all that stuff you don't have subspace anymore, you have a totally new game tongue.gif
Qndre> But it will still work on the same servers.
Starpocaly> lol
Qndre> You can still play DSB.
Moon> really?
Qndre> With the same graphics.
Starpocaly> and i'll be there if needed icon_smile.gif
Starpocaly> cause im gonna play it if it has finished
Kerendin> play what?
Qndre> And no zone has to use the physics if it doesn't want to
upk> if there were physics, you could not smash walls or other ships
Qndre> But the main feature shouldn't be physics.
Qndre> The main feature should be an application "between" the webbrowser and continuum.
Qndre> It makes everyone with a webbrowser able to spectate games.
Qndre> It would be a CTM client and a web server.
odd> now see, that's your problem, is usefulness.
odd> who in the hell would do that when you could just load continuum
[..]

Mr Ekted - Mon Feb 23, 2004 5:46 pm
Post subject:
Let's all take a look back on the laugher and the the tears that is Qndre...

Qndre wrote:
There are some people, who already cracked the checksum/encryption-system and published the algorithm on their websites. The client builds a checksum of the "subspace.exe", does some other encryption-like-things and finally adds some time-codes and hardware-fingerprints (I will set the hardware-fingerprint to a random number for my client) to it. The complete algorithm can be found on bot-related websites like those of the MERVbot server system.


Qndre wrote:
I know. I even know the formula it uses. It's on the web.


Qndre wrote:
You will get the complete algorithm if I've put the information together.


Qndre wrote:
Sent 00 01 core packet to the server with 00 00 encryption key. Server didn't respond. Sent 00 01 core packet again this time with FF FF encryption key. Server responded, gave me a timecode and asked for my timecode. I sent server's time code back but he didn't respond. How do I generate a valid timecode and pingtime?


Qndre wrote:
The server wants timestamps. How do I generate one?


Qndre wrote:
What does this "clock" count?? The duration since sending the 00 01 core packet (connecting) or the time (like 4:30 pm at example)? The clock changes every second or every 1/10th or every 1/100th? Is it all seconds or hh:mm:ss or something like that? It also requires a ping time. What's that? Why doesn't he simply send a packet and I reply and then he knows the ping I have (like "ping" in command line does)?


Qndre wrote:
Continuum is written in Borland's TurboPascal


Qndre wrote:
If I try to decompile "Continuum" using RE-C I get the error message "REC - 139 lines left / can't decompile / this EXE file is written in TurboPascal / reverse engineering aborted"!!


Qndre wrote:
I've got some questions about VIE encryption because everyone gives me other information and I can't try out everything. Well... Packet headers are unencrypted but the data which follows is encrypted? If I send data to the client do I have to encrypt it as well or is the server sending encrypted packets to the client and the client responds unencrypted? Which key do I have to use for what? If I look at the protocol document the server sends a key and my client sends a key. If you aren't behind the login sequence then packets are also encrypted? Where do I have to put my machineID? It can be random? What about the password? Does it use another encryption than the rest of the data? In the profile file the password is encrypted. Do I have to send this encrypted password or the plain-text? Is the encrypted or plain-texted password also encrypted using one of the keys? Using which one? Please just give me everything you know about it. (Already downloaded sourcecode of Subspace client but I don't understand because I am not able to do C.) Chunked packets and Filetransfer (LVL, LVZ) are also encrypted? I heard about reliable messages? I'll have to respond with an ACK. Is it encrypted? Are the security checksums encrypted? Are they using a different algorithm than the rest?


Qndre wrote:
But how can the system execute a packed binary file? Every EXE-file (except 32-/64-bit files) is directly written into the CPU. How can the CPU execute the file if it's packed?


Qndre wrote:
The Continuum-encryption is 16-bit (64000 different keys). A computer can crack it within some seconds.


Qndre wrote:
I am not ignorant. I just want to write the application as fast as possible, because I am really busy.


Qndre wrote:
And I've written a webserver


Qndre wrote:
And I've even written an "unencrypter" or crack for the MD5 encryption but that software isn't useful because MD5-encryption takes thousands of years to deincrypt


Qndre wrote:
Yes I know even if all the people I know say "that's not right - every MD5 is unique". But I know that it can't be true because a 128-bit value can't take more than 3.402823669+E38 values. And that's why I know that Continuum encryption can't be too difficult to crack. It's a 16-bit-key and a 16-bit-value can't take more than 65536 (yes the magic computer number) different values. And that's not very much.


Qndre wrote:
But it can't be illegal to look at the source of Subspace because it is OPEN SOURCE!!!!


Qndre wrote:
Can't find the website of VIE. Already searched Google for it.


Qndre wrote:
It's open-source because Snrrrubspace is open source and Snrrrubspace is equal to Subspace.


Qndre wrote:
About Continuum encryption which...It's a very very very very very very simple encryption.


Qndre wrote:
And if I look at the packetlist I see it uses a 32-bit key not a 16-bit key but someone else told me it was 16-bit and I asked him if he was sure and he said "Yes!".


Qndre wrote:
I'm sorry my idea has to end like this. I'll try to realize it on my own...


Qndre wrote:
I guess the server won't believe that I am a Continuum client because if use the old encryption but new version bytes but maybe it only checks what's in the version bytes. If it only checks the version byte then I've won.


Qndre wrote:
I believe that MGB knows what he's doing because he seems to be very experienced.


Qndre wrote:
So I set the key to FF FF FF FF and then I'll only have to invert the data I get and the data I send because XOR 11111111 is the same as invertion and then I've got the plaintext.


Qndre wrote:
Yes. You have a continuous bitstream between the server and the client. And there is a keystream and a bitstream. At example:

Bitstream: 100101110010010100010101011110010101000101001111
Key: 11010010101010101100110010100111

In this example the bitstream is 48 bit long (6 bytes - in reality it's "inifinite"). The key is 32 bits long (4 bytes - in reality it's also 4 bytes). Now you make the key as long as the bitstream by putting many keys after each other so the resulting stream is as long as the bitstream.


Qndre wrote:
But the most real encryption don't work like that. But I guess Continuum does but that's just a guess


Qndre wrote:
You want to fool me? The whole Continuum is not that long. My self-written GUI is about 4000 lines in BASIC (not C) but CONTINUUM?? *laugh*


Qndre wrote:
I've got an online contact who helped by the development of the Continuum client. He told me something else. I trusted him.


Qndre wrote:
I read Continuum was open-source. Snrrubspace has written another client. How was he able to do that if no one except PriitK has the source.


Qndre wrote:
What is a "spoof check" and a "spoof reply". I saw the official definition is "Sync Request" and "Sync Reply". Do you mean the same?


Qndre wrote:
But S2C (server to client) 00 05 is also sync packet. Look at the packet list of ExplodyThingy and please correct me if I'm wrong.


Qndre wrote:
In what should I believe? I see this on the packet list but you give me different information.
So if I've worked with the packetlist till now then I can't do anything because the 0x0005 is the second packet which is exchanged between Server and Client. Please tell me the correct parameters of the 0x0005 core packet. Maybe I can solve my problems this way.


Qndre wrote:
OK. Thanks for that information. But what does "Intel order" mean?


Qndre wrote:
Do you still think I'd be a noob?


Qndre wrote:
Why don't call gettickcount() in the Basic application? Because Basic doesn't support that function. Even if I declare it.


Qndre wrote:
In one of my projects I had a problem and it took months just to find out what's wrong and then some weeks to correct.


Qndre wrote:
You've told me that CTM generates a hard-to-guess keystream.

I've got a solution

You have a key:

FF AE 64 FF

And you have a continous keystream between client and server. At example:

Code:

57 47 A5 86 A8 59 2A 36 48 56 AA 39 8A 57 76 A4 35 A8 6A 23 48 97 A5 24 45 6A 3A A2 8A 55 A2 A5 98 7A 46 5A A8 3A A2 65 AA 98 2A 63 45 6A 43 A9 85 ...

This was just an example, not a valid keystream.
And this keystream (not the key itself) is just simple-xorred with the data. Please don't say "that's not true" because I KNOW IT FOR SURE.

I guess that I can't use ANY keystream (at example FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ...) for encryption but any key. But the keystream has to be something specific depending on what key you've set in the 00 01 core packet (I guess). I'll try it out. If I can take ANY keystream then it's very very simple. If I can't take any keystream then I'll have to figure out how to generate a valid one (or just steal ONE of the keystreams out of CTM by figuring out the I/O). The original CTM client generates this keystream and encrypts its packet with it. So that should be the solution. I capture ONE of the keystreams the CTM client uses (after some time it becomes periodic because every encryption does) and I look at the 00 01 core packet. Then my application uses EXACT THIS key because of the other keys I don't know the keystream. That's the solution.


Qndre wrote:
So you mean it would take 300-400 days? That's not too much. I've even done projects some years after starting them.


Qndre wrote:
Found out something new. The Subspace (not CTM) keystream is 4160 bits long. CTM is about 272629760 bits long (10400000 in hex value). But I don't know it for sure ...
So if the keystream is this long, then trying to crack it using brute-force doesn't work.


Qndre wrote:
I ONLY WANTED TO SAY THAT IT IS POSSIBLE TO CRACK IT NOT THAT I WOULD DO IT IMMEDIATELY


Qndre wrote:
I'm not a newbie. I'm not inexperienced.


Qndre wrote:
I don't need assistance in setting up a UDP connection with a server because I know how to form UDP packets and I've already written some network-applications which work correctly. And I never use TCP in my apps because it's slow.


Qndre wrote:
I can't login yet. I'm far away of that.


Qndre wrote:
I sent a 00 01 FF FF FF FF 01 00 core packet.

Subgame gave me 00 05 core packet.

I responded with:

00 06 00 00 00 0A TT TT TT TT

TT TT TT TT = "Int(gettickcount() / 10)" as a little endian hex value.

Subgame didn't respond.

Seems like the response I gave wasn't correct, was it? I only want to know because then I'll have to search for the problem somewhere else.



Ekted wrote:
You must send back the same value in the 0006 packet that you received in the 0005 packet. That's how a spoof check works.


Qndre wrote:
Er... If I look at the packetlist then I see that I have to send my ping and my tick counter.


Ekted wrote:
We've been through this. The comments and names for that packet are incorrect in this case. This is why I have been calling it the spoof packet and not the sync packet. But since you don't listen to me, you keep on doing it wrong.


Qndre wrote:
Hey!! Thanks!! It works!! *jump around*


Qndre wrote:
Now I'll have to send a login packet. I won't ask anything here if I don't have to. And then the VIE encryption begins. I've got the C-Code of the encryption. I'll take some time to learn C and figure it out on my own.


Qndre wrote:
About VIE encryption:
I'll have to encrypt everything but the 09 packet header, right? Everything is encrypted except packet headers.
*hrmpf* VIE encryption is so hard to implement ...


Ekted wrote:
It's been 29 days, and so far you've managed to send 2 correct packets...


Qndre wrote:
but I can't do the encryption because I don't understand how it works.



For the record, to date we have:

- 2 valid packets figured out
- inability to login
- inability to figure out encryption despite "how so very very simple it is"

Did I miss anything?
nintendo64 - Mon Feb 23, 2004 5:46 pm
Post subject:
Mr Ekted wrote:
It's been 29 days, and so far you've managed to send 2 correct packets...


29 days... and still many more days before this is finished... and you are already advertising it? don't you want to wait to see if you CAN do it?

Ekted you missed the point, he's already advertising it, like it is going somewhere...

-nintendo64
Qndre - Mon Feb 23, 2004 6:01 pm
Post subject:
I've got a question: Why does every application generate the checksum out of "subspace.exe" instead of just including the instant checksum which is ready to be sent out together with other checksums which have to be generated (like the one of the map, settings, etc.)?
Mr Ekted - Mon Feb 23, 2004 6:14 pm
Post subject:
It's not a fixed value. The checksum is calculated from a key the server sends which is combined using feedback with the data being checksummed. So you always need the raw data available. My bots embed the parts of the EXE that it needs as data, so it doesn't have to open subspace.exe as an external file.
Dr Brain - Mon Feb 23, 2004 9:32 pm
Post subject:
Learn C. Come back in a year.
Qndre - Tue Feb 24, 2004 5:26 am
Post subject:
Mr Ekted wrote:
It's not a fixed value. The checksum is calculated from a key the server sends which is combined using feedback with the data being checksummed. So you always need the raw data available. My bots embed the parts of the EXE that it needs as data, so it doesn't have to open subspace.exe as an external file.

You have an EXE-checksum, a MAP-checksum, etc. and the EXE-checksum is a fixed value as far as I know. It's combined with the server key. So what? I can also combine a fixed number with the server key so that it changes when the server key changes.

I'll use this VIEenc plugin now so I don't have to care about encryption and then I'll try to send a valid 0x09 packet. I'll see what happens. I'm just too busy at the moment to try it out immediatelly.
Jason - Tue Feb 24, 2004 7:16 am
Post subject:
Dude, just go off and do some work on this for awhile. You come back to these forums and post what you're up to like a radio announcer would do a play-by-play of a baseball game. It's not necessary.
Mr Ekted - Tue Feb 24, 2004 11:46 am
Post subject:
Qndre wrote:
You have an EXE-checksum, a MAP-checksum, etc. and the EXE-checksum is a fixed value as far as I know. It's combined with the server key. So what? I can also combine a fixed number with the server key so that it changes when the server key changes.

I'll use this VIEenc plugin now so I don't have to care about encryption and then I'll try to send a valid 0x09 packet. I'll see what happens. I'm just too busy at the moment to try it out immediatelly.


Every time you ask me a question, and I answer, and you disagree, you come back asking why your way doesn't work. Then you realize I was right 7 pages ago. Learn from your mistakes if you want help.
Qndre - Tue Feb 24, 2004 11:52 am
Post subject:
Yes. As for my physics engine I posted in SSforum.net: http://www.ssforum.net/index.php?showtopic=2968
Catid wrote:

Qndre seems to be rather annoyed at all the poo-pooing.

It's a solid idea based on established physics approximations, and I'd love to see an implementation of these things in Continuum. Eh, mainly just for Metal Gear.

So you see not everyone thinks that my idea is trash. biggrin.gif

I'll take this advice:
Quote:

Every time you ask me a question, and I answer, and you disagree, you come back asking why your way doesn't work. Then you realize I was right 7 pages ago. Learn from your mistakes if you want help.

Mr Ekted - Tue Feb 24, 2004 1:13 pm
Post subject:
No one said your idea was bad. That thread on ssofurm degraded into a discussion of how to implement drag, if drag should be used, how SS/Cont currently work, various arena settings, etc. This is why I said, "Is everyone discussing the same topic here?". However, it's still rather pointless for you to be posting code for us; those who would add new features would be able to do so in a much more efficient way, and in a way that integrates with all the other existing physics. Simply suggesting that a friction setting be added for ship would be sufficient.
Qndre - Tue Feb 24, 2004 2:08 pm
Post subject:
OK. I suggested catid to shorten his checksum algorithm. And he did. And he open-sourced it.
Quote:

Hello. Qndre was talking with me today, and he mentioned that the VIE EXE checksum generator looked like it could be done without the actual EXE file. So, i wrote this PoC. Can someone check it for me?

Uint32 generateEXEChecksum(Uint32 key)
{
Uint32 part, csum = 0;

part = 0xc98ed41f;
part += 0x3e1bc | key;
part ^= 0x42435942 ^ key;
part += 0x1d895300 | key;
part ^= 0x6b5c4032 ^ key;
part += 0x467e44 | key;
part ^= 0x516c7eda ^ key;
[..]

Thanks for telling my name but it's still your algo, catid. biggrin.gif I only had the idea.
nintendo64 - Tue Feb 24, 2004 2:28 pm
Post subject:
@Mr Ekted> you might want to check this thread

http://www.ssforum.net/index.php?act=ST&f=4&t=3011&st=0#entry39525

-nintendo64
Qndre - Tue Feb 24, 2004 3:03 pm
Post subject:
Which idea was whos? It's simple:
Quote:

Including parts of the exe was Mr. Ekted's idea.

Just take a constant and combine it with the key later (without having the raw data) was mine.
Mr. Ekted wrote:

So you always need the raw data available.


Mr Ekted - Tue Feb 24, 2004 3:55 pm
Post subject:
Qndre, you are like a child walking up to a guy building a skyscraper. You hold out your tiny hand containing a piece of metal and say, "You should use this in your building." And when the building is complete you say, "See. Those girders were my idea." You are way out of your league to be suggesting code here or on ssforum. Use them as a way to learn, stop pretending you are trying to teach anything, and you will find people more receptive.
Qndre - Tue Feb 24, 2004 4:27 pm
Post subject:
Yes, OK. I'm far from being an experienced programmer. But one thing I really don't understand is one thing which is related to VIE encryption. I give the server an encryption key in my 00 01 core packet. But after the spoof check he sends a 00 02 core packet back which is also containing an encryption key (look at the packetlist). Which key should I use for what?
Mr Ekted - Tue Feb 24, 2004 5:05 pm
Post subject:
00 02 is the connection reply packet. If it accepts your key it will reply with the negative value. Use your key to encrypt.
Qndre - Tue Feb 24, 2004 5:10 pm
Post subject:
Mr Ekted wrote:
00 02 is the connection reply packet. If it accepts your key it will reply with the negative value. Use your key to encrypt.

Catid in ICQ wrote:

Catid (10:48 PM) :
the 00 02 contains the REAL encryption key that you use.
[..]
Qndre (11:07 PM) :
Mr. Ekted told me to use the key in the 00 01 core packet to encrypt not the one in the 00 02 packet. You said I should use the one in 00 02 , right?
Catid (11:09 PM) :
yeah
Qndre (11:09 PM) :
I'll tell him.

(Time is GMT + 1)

Why do I ask if I have to try out everything on my own? biggrin.gif
Mr Ekted - Tue Feb 24, 2004 5:23 pm
Post subject:
Ooops, he's right. I typed it without checking. I remembered it backwards.
Qndre - Wed Feb 25, 2004 9:50 am
Post subject:
k so CatID was right. Thanks for all your help.
Qndre - Sat Mar 06, 2004 8:35 am
Post subject:
grav_new.gif
WOW! First great success! icon_biggrin.gif
Now my program has five modules and it works a bit. biggrin.gif I can log on to VIE and ForceContinuum zones (Just set the client version to CONTINUUM in the 00 01 core packet and to VIE in 09 game packet - I can use VIE encryption on ForceContinuum zones now! Is it a bug? Nice bug! biggrin.gif ). Then I get a huge data-flood of reliable-packets, chunks and clusters. icon_sad.gif I'll have to enhance my handler since it doesn't handle much packets, yet. biggrin.gif

So clusters, chunks and reliable packets are difficult to handle? icon_eek.gif But I'm lucky to get help from Catid (THANKS) biggrin.gif .

So... You still think it's impossible? icon_wink.gif
_
PS: I don't know how far I get with this method because maybe server kicks me out later if it recognizes that I am NOT Continuum client but VIE. Don't know but I've got many options in my software so I can log on using VIE signature as well.
Smong - Sat Mar 06, 2004 11:52 am
Post subject:
In a ForceContinuum zone, VIE clients can probably stay in spec, but cannot get in a ship.

If the server has security checks turned on, you may get kicked for not returning the correct checksums and stuff.

Also if you miss too many reliable packets you will probably get kicked off the server for 'no data' or something. Since (with vie enc) packet headers aren't encrypted, it is easy to change the 0x03 to an 0x04 and send back the first 6 bytes as the acknowledge.
Mr Ekted - Sat Mar 06, 2004 2:24 pm
Post subject:
Some zones allow VIE in spec mode. If a given zone does not, it will boot you when you try to talk to it using VIE. Try SSCX Powerball as a good test...but not too many times, we get sysop warnings.
Qndre - Sat Mar 06, 2004 3:19 pm
Post subject:
Smong wrote:
In a ForceContinuum zone, VIE clients can probably stay in spec, but cannot get in a ship.

If the server has security checks turned on, you may get kicked for not returning the correct checksums and stuff.

Also if you miss too many reliable packets you will probably get kicked off the server for 'no data' or something. Since (with vie enc) packet headers aren't encrypted, it is easy to change the 0x03 to an 0x04 and send back the first 6 bytes as the acknowledge.

Yes. Reliable packets aren't computed by my client yet but it sends out an ACK packet so that's no problem. Client also responds to ping but doesn't give position packets and security checksums yet. This will be the next step.

Quote:

Since (with vie enc) packet headers aren't encrypted, it is easy to change the 0x03 to an 0x04 and send back the first 6 bytes as the acknowledge.

No need to do this because I can implement encryption using Catid's DLL (will be replaced by my own plugin later but thanks for that).
And Mr Ekted - I'll try it if I am able to stay on my own server without getting kicked (yes - a few seconds after arena login I get kicked out), OK?
Qndre - Sat Mar 06, 2004 4:16 pm
Post subject:
Solved some other probs. Security checksums and position checksums are the problems at the moment:
Quote:

Connection request from: SpecBOT
Arena Created: () using parameters: E:\subserver\server.cfg
Sat Mar 06 22:13:43: Ext: Loading level file: source.lvz
Player spectating game: SpecBOT
Sat Mar 06 22:13:45: C2S position packet checksum error (SpecBOT)(-947630654)(1
92.168.0.3)(sec=3)
Sat Mar 06 22:13:45: Arena dropped

I need to figure out how to create a valid position checksum. Maybe I find some information in Catid's bot. But one question (just that I don't do it all wrong): I have to send position packets even if I am not in game but a spectator, haven't I?
_
Edit:
Maybe I've found a solution! Snrrrub does it like this:
Quote:

for(uint32 cnt = 0; cnt < 22; cnt++)
checksum ^= thePacket[cnt];

cnt is the indicator which shows which byte of the packet should be read. So for the checksums it uses each byte to XOR them with each other until byte 22. So in basic it should be like this:
Code: Show/Hide

checksum = 0
for i = 1 to 22
checksum = checksum xor asc(mid(packet, i, 1))
next i

Edit:
new_shocked.gif - It works!! biggrin.gif biggrin.gif biggrin.gif biggrin.gif biggrin.gif biggrin.gif biggrin.gif
Connection is established and kept-alive although my software is NOT VIP and doesn't return security checksums. Cool. Simpler than I thought.
Let's celebrate. *laugh*
nintendo64 - Sun Mar 07, 2004 12:50 am
Post subject:
Qndre do this for a completely Continuum-only server.

First,

On server.ini
AllowVIEClients=0
ForceContinuumOnly=1

On server.cfg
[Misc]
ContinuumOnly=1

i don't remember others if you have all three active try your "trick" and see if it works. I'm pretty sure what smong and ekted debscribed is truth.

Btw remember what i said about sysop and smod access they can still enter EVEN IF IT ISN'T ON VIP.

Yes indeed about the Simple Checksum or Position Packet Checksum, simple xor.
Code: Show/Hide
function TSS.Poke03ChecksumAt0A(const Packet03:String): String;
var
    n: LongWord;
    c, Tot: Byte;
begin
    Tot := 0;
    for n := 1 to $16 do
    begin
        c := OrdInt(Copy(Packet03,n,1));
        if n = 11 then c := 0;
        Tot := Tot xor c;
    end;
    Result := Copy(Packet03,1,10) + Chr(Tot) + Copy(Packet03,12,Length(Packet03)-11)
end;


-nintendo64
Anonymous - Sun Mar 07, 2004 4:59 am
Post subject:
People beginning projects to write new clients is as passé as people writing their own bot core was a couple years ago.

And why do you unoriginal idiots begin your projects repeating the same shit (...familiarization with silly nuances of net protocol...bitching about priitks tightfistedness with all things cont... etc.) that's been done tens of times by people who can't possibly be less experienced than you? READ FIRST THEN ASK.

All these stupid redundant questions and answers largely end up being thinly veiled pissing contests between people who'd like to hide their uselessness.

It's nice to have some open discussion on these subjects, but it gets old seeing people needlessly and hopelessly repeat things so that they can say that they did their project alone.
Doggeti - Sun Mar 07, 2004 8:55 am
Post subject:
Here's a little question in between:

The first byte in a server request packet is 00, right? So you do msg[0] = 0x00;
Now, if msg is a char-array 00 is also 0 or '\0', isn't it? So if you send this message to the server wouldn't it stop right at the first byte?
I don't understand how this can work.
Qndre - Sun Mar 07, 2004 9:49 am
Post subject:
nintendo64 wrote:

if you have all three active try your "trick" and see if it works

First I had the following settings:

AllowVIE = 1
ForceContinuumOnly = 0
ContinuumOnly = 0

Then I tried with:

AllowVIE = 0
ForceContinuumOnly = 1
ContinuumOnly = 0
And it worked.

Now I tried with:

AllowVIE = 0
ForceContinuumOnly = 1
ContinuumOnly = 1

Only that forced my client out! The server logged:
Quote:

Connection request from: SpecBOT
Sun Mar 07 15:43:04: Incompatible network protocol attempting to enter game (SpecBOT)(-1066650737)(192.168.0.3)(sec=1)

So the server recognized that I used wrong encryption. But most zones only set "AllowVIE = 0" and "ForceContinuumOnly=1" and forget to set "ContinuumOnly = 1" so my client can enter.

About Doggeti:
I don't even understand the question. biggrin.gif

PS: My software can enter zones which have "AllowVIE = 0". It can also enter if "ForceContinuumOnly = 1" but not if "ContinuumOnly = 1" because "AllowVIE" and "ForceContinuumOnly" are only looking at the version byte while "ContinuumOnly" is looking at the encryption.
Mr Ekted - Sun Mar 07, 2004 12:01 pm
Post subject:
Doggeti wrote:
Here's a little question in between:

The first byte in a server request packet is 00, right? So you do msg[0] = 0x00;
Now, if msg is a char-array 00 is also 0 or '\0', isn't it? So if you send this message to the server wouldn't it stop right at the first byte?
I don't understand how this can work.


It's called interpretation. Values stored in memory are interpreted the way they are defined in the code. Memory with the data 0x41 0x42 0x43 0x00 that is declared as a string will be interpreted as "ABC" with a null terminator. If it is declared as an int, it will be interpreted as 0x00434241 or decimal 4,407,873. Packets are just blocks of bytes of arbitrary length. An application can interpret the contents of the packet however it wants.
Mr Ekted - Sun Mar 07, 2004 12:04 pm
Post subject:
The most efficient way to calculate the position packet checksum is to zero the checksum first. That way you don't have to check for it every iteration, as in nintendo's posted code.

Code: Show/Hide
pkt[11] = 0;

for (i = 0; i < 22; i++)
   checksum ^= pkt[i];

pkt[11] = checksum;

Mr Ekted - Sun Mar 07, 2004 12:10 pm
Post subject:
Qndre wrote:
Reliable packets aren't computed by my client yet but it sends out an ACK packet so that's no problem. Client also responds to ping but doesn't give position packets and security checksums yet. This will be the next step.


It is not sufficient to simplysend an ACK at the expected point in time. You must implement a reliability layer in your networking code for both the receiving and sending sides. Here's a sample sequence for the receiving side. All numbers are reliability sequence numbers.

Code: Show/Hide
recv 0
ack 0
process 0
recv 0
ack 0
recv 2
ack 2
recv 3
ack 3
recv 500 (do not ack, outside window)
recv 1
ack 1
process 1
process 2
process 3
recv 2
ack 2
recv 4
ack 4
process 4


If this does not make sense to you, then you need to stop and figure it out.
Qndre - Sun Mar 07, 2004 12:25 pm
Post subject:
Mr Ekted wrote:
The most efficient way to calculate the position packet checksum is to zero the checksum first. That way you don't have to check for it every iteration, as in nintendo's posted code.

Code: Show/Hide
pkt[11] = 0;

for (i = 0; i < 22; i++)
   checksum ^= pkt[i];

pkt[11] = checksum;

I already have done that. biggrin.gif I'm a step further than you think. icon_biggrin.gif And I have set checksum to 0. *laugh* I solved the problem before nintendo's post. I solved it by looking at Snrrrubspace source.
As for your reliability layer - I understand. If there is a packet missing you'll have to get it in order to compute the others. If a packet arrives you have to send ACK immediatelly.

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 .. 17 18 19
So I'll have to wait until 16 arrives. But how do I know the order? Is it the 4-byte-ACK-ID?
But I don't compute reliable packets, yet so the reliable stack doesn't work yet (only ACK is sent out) but this will be the step after I have completed the security checksums algorithm.
nintendo64 - Sun Mar 07, 2004 12:30 pm
Post subject:
Qndre wrote:

after I have completed the security checksums algorithm.


are you planning to implement Catid's VIE EXE Checksum Generator?
if so be sure to test it thoroughly.

-nintendo64
Mr Ekted - Sun Mar 07, 2004 12:36 pm
Post subject:
Qndre wrote:
Is it the 4-byte-ACK-ID?


The 4 byte value in the 00 03 and 00 04 packets in the reliability sequence number--what you call the ack id.

00 03 SS SS SS SS ...
00 04 SS SS SS SS

Also the first value is 0, not 1.
Anonymous - Sun Mar 07, 2004 4:17 pm
Post subject:
Ekted, how big is the ack 'window'? Does it vary in size according to latency? If so, what is the formula?
Cyan~Fire - Sun Mar 07, 2004 4:27 pm
Post subject:
It's nice to see you making some good progress and thinking for yourself Qndre. I take back almost all of my harsh words earlier icon_smile.gif

@divine.216: Sure, bots have and at least one client has been written before. But making a new one is a great learning experience. If you want to learn a language thoroughly, creating a large program that has some practical use is a very good way of doing so (especially if it includes networking). So, don't talk trash to him just for attempting this.
Mr Ekted - Sun Mar 07, 2004 4:33 pm
Post subject:
-Smong- wrote:
Ekted, how big is the ack 'window'? Does it vary in size according to latency? If so, what is the formula?


I believe the window used by both the server and the client is 128. There's also another threshold: if the server has 255 reliable messages queued up for you and you do not ack fast enough, you get dropped. This is the sourceof the server log messages like:

Reliable packet lost(xx) to: xxxxxxxx (pending=366 current=621 diff=255)
Mr Ekted - Sun Mar 07, 2004 4:36 pm
Post subject:
Cyan~Fire wrote:
I take back almost all of my harsh words earlier.


I don't. He's still a newb. He's far from being able to do anything useful. He doesn't even know what he doesn't know. Every time he figures out a new byte in the protocol, he acts like he's done. Then 3 days later he comes back clueless.
wEaViL - Sun Mar 07, 2004 9:12 pm
Post subject:
Mr Ekted wrote:
[..]



I don't. He's still a newb. He's far from being able to do anything useful. He doesn't even know what he doesn't know. Every time he figures out a new byte in the protocol, he acts like he's done. Then 3 days later he comes back clueless.


Ok..... Seems to me hes getting somewhere with it.... Still dunno what we would do with this program....
Qndre - Mon Mar 08, 2004 5:03 am
Post subject:
Cyan~Fire wrote:

It's nice to see you making some good progress and thinking for yourself Qndre. I take back almost all of my harsh words earlier

@divine.216: Sure, bots have and at least one client has been written before. But making a new one is a great learning experience. If you want to learn a language thoroughly, creating a large program that has some practical use is a very good way of doing so (especially if it includes networking). So, don't talk trash to him just for attempting this.

Thanks! I know I'm far from being a useful programmer. But I knew that I wouldn't be able to finish my project without learning new stuff because my experience was much too small. So I started this project to get better in programming. I know that I haven't wasted my time even if all I learned would be how UDP protocol works and how I use GetTickCount() function and what little-endian means.
wEaViL wrote:

Ok..... Seems to me hes getting somewhere with it....

Yes. I'm getting somewhere but maybe not where I want to get and even if I do then it will take much time because I'm not an experienced programmer. Nobody is perfect but I also don't say that I am because I know that I'm not.
wEaViL - Mon Mar 08, 2004 9:34 am
Post subject:
I didnt mean for that to sound bad.... was just saying that Mr Ekted is being a jerk... I agree with Cyan~Fire on it... its a good thing that your making progress on it and that your learning new things.... Its nice to see people putting there idea to a use instead of it just remaining a idea....

Cant wait to see the stable release in the future.
Qndre - Mon Mar 08, 2004 11:23 am
Post subject:
wEaViL wrote:
I [..] was just saying that Mr Ekted is being a jerk.

What does the word "jerk" maen? Sounds like something negative?
wEaViL - Mon Mar 08, 2004 12:08 pm
Post subject:
It is lol
Code: Show/Hide

Dictionary.com
Jerk is:
Slang. A foolish, rude, or contemptible person

Qndre - Mon Mar 08, 2004 1:03 pm
Post subject:
Csum algo only works in C. *gaber*
*settingmysoftwareintosysopmodeattheserverfirst*
*implementingchecksumalgorithmlater*
Mr Ekted - Mon Mar 08, 2004 2:22 pm
Post subject:
wEaViL wrote:
was just saying that Mr Ekted is being a jerk


Please go back and read through the entire thread. If Qndre had simply come here looking for help, and accepted it, all would be fine. But he had to tell everyone who was trying to help him that they were wrong, and that what he was going to do was going to be so easy. Any reasonably adequate programmer would have had something working within a day or two, especially given that the source code for it all is freely available, and that Qndre was touting all the stuff he'd previously done. I, personally, am enjoying throwing his wild claims right back in his face just because of his attitude (if you are going to give attitude, expect to get some back). On the other hand, I have still been answering his posts with enough information to take him to the next step.
Qndre - Tue Mar 09, 2004 9:39 am
Post subject:
Why do they make it so difficult?

- There are 8-bit (game) and 16-bit (core) headers (so what?)
- There is a reliability layer (which is simple to handle)
- There is encryption (which is nearly impossible to do without a plugin)
- There are checksums (security and position checksums)
- There are version signatures (which are very weak)
- There is this little-endian stuff (which confuses me much)*

* = Some values have to be reversed in their bytes, others don't
Mr Ekted - Tue Mar 09, 2004 10:03 am
Post subject:
Qndre wrote:
Why do they make it so difficult?

- There are 8-bit (game) and 16-bit (core) headers (so what?)
- There is a reliability layer (which is simple to handle)
- There is encryption (which is nearly impossible to do without a plugin)
- There are checksums (security and position checksums)
- There are version signatures (which are very weak)
- There is this little-endian stuff (which confuses me much)*

* = Some values have to be reversed in their bytes, others don't


Don't know what you mean by 16-bit core headers.

Reliability layer is there to guarantee reception and order of important things (map, settings, players, messages, etc). The game would not work without it.

Encryption is easy, and easy to do without a plugin. It is less than a page of C code, and the source is freely available.

The checksums (code, map, settings) were originally put there by JeffP (of VIE) to make sure people didn't cheat by 1) modifying the client itself, 2) modifying the map in memory, 3) modifying the settings in memory. Since these are all known now, the VIE client is the source of too many cheats to allow people to use it to play. However if you want to be able to make a bot that stays connected (without sysop powers) you still need to act like a VIE client.

Version signatures. I don't know what you mean by this.

Little endian stuff is NOT a design feature. It is the way Intel/AMD store 2-byte and 4-byte values in memory. And if you wrote your code in C, you would not even have to think about this as it happens automatically. If you build your packets a byte at a time (which is absolutely the wrong way to do it) then you do have to worry about it--and it's your own fault.
Dr Brain - Tue Mar 09, 2004 11:35 am
Post subject:
Mr Ekted wrote:
Little endian stuff is NOT a design feature. It is the way Intel/AMD store 2-byte and 4-byte values in memory. And if you wrote your code in C, you would not even have to think about this as it happens automatically. If you build your packets a byte at a time (which is absolutely the wrong way to do it) then you do have to worry about it--and it's your own fault.


Just curious, what IS the right way to do it?
Mr Ekted - Tue Mar 09, 2004 11:40 am
Post subject:
Create a structure that defines the packet and set its members. Such as...

Code: Show/Hide
struct PktConnect
   {
   BYTE  type1;
   BYTE  type2;
   DWORD key;
   };


The only trick is to force packing. In VC you would use:

Code: Show/Hide
#pragma pack(1)

Dr Brain - Tue Mar 09, 2004 12:57 pm
Post subject:
Mr Ekted wrote:
Create a structure that defines the packet and set its members. Such as...

Code: Show/Hide
struct PktConnect
   {
   BYTE  type1;
   BYTE  type2;
   DWORD key;
   };


The only trick is to force packing. In VC you would use:

Code: Show/Hide
#pragma pack(1)


Cool. That's the way I have been doing it.
Qndre - Tue Mar 09, 2004 1:25 pm
Post subject:
OK, I understand.
Coconut's sasme.dll uses these calls to calculate security checksums:
Code: Show/Hide

   Seed& = StringToLong(Right(Packet18$, 4))
   If Seed& <> 0 Then
       ParameterChecksum& = SSParameterChecksum1A(Settings$, Seed&)
       CodeChecksum& = SSCodeChecksum1A(SubspaceBin$, Seed&)
       LevelChecksum& = SSLevelChecksum1A(MapBuffer(0, 0), Seed&)
       '
       SendTo ReliableHeader & Chr(&H1A) & LongToString(0) & _
         LongToString(ParameterChecksum&) & _
         LongToString(CodeChecksum&) & _
         LongToString(LevelChecksum&) & _
         String(23, 0)
   End If

But "LongToString" and "StringToLong" are NO VB COMMANDS!!
Mr Ekted - Tue Mar 09, 2004 1:38 pm
Post subject:
I'm sure he has those functions defined elsewhere in his code. Btw, do not assume that the function names are what they say.
Qndre - Tue Mar 09, 2004 2:04 pm
Post subject:
Y shouldn't they do what they are called?
Btw, this code is 100% assembler - this is just the example how to use it.
_
Another question: At the very beginning of this thread you said if I was spectating at a specific area I couldn't get position data from areas which aren't on my screen (with 1280x1024).
Mine GO BOOM wrote:

The problem with this method is, that all clients only get position data around them only. So if you are specating around E6, you won't see anyone at J12.

But Subspace can generate a R.A.D.A.R. view which also shows other ships. So it has to get position packets from nearly all over the map (or at least how much the R.A.D.A.R. shows). *dontunderstand*
Mr Ekted - Tue Mar 09, 2004 2:12 pm
Post subject:
Well, it's not my code. Ask the writer why they are called LongToString etc. It's partly because in basic, they treat packets like a string, packeting and unpacking them using chr$() etc, which is so damn inefficient. But whatever. My point was, don't assume LongToString() has anthing to do with a real string. It probably just takes a value and write it out as 4 bytes in the order they would be written if basic could handle structures.

In C, if you did "packet.value = 0x12345678" the asm would be something like:

Code: Show/Hide
mov [addr], 12345678


In basic, the LongToString (at best) would translate to:

Code: Show/Hide
mov byte ptr [addr], 78
mov byte ptr [addr+1], 56
mov byte ptr [addr+2], 34
mov byte ptr [addr+3], 12

Qndre - Tue Mar 09, 2004 2:15 pm
Post subject:
icon_confused.gif
k
_
But what about the position-data? The R.A.D.A.R. can "look" really far.
Smong - Tue Mar 09, 2004 2:18 pm
Post subject:
template.sss wrote:
Routing:RadarFavor:1:7:Number of packets somebody on radar receives (1 = every packet, 3 = every fourth packet, 7 = every eighth packet)

Mr Ekted - Tue Mar 09, 2004 2:58 pm
Post subject:
From the client's point of view, you don't care. You get whatever position packets the server chooses to send to you.
Dr Brain - Tue Mar 09, 2004 3:09 pm
Post subject:
For example: There is a command under ASSS that tells the server to give a certain player all the position packets in the arena. This is used for bots only, as it's almost totally useless to a normal player.

The client has no say in what position packets get forwarded. Now, generally the server is nice and sends position packets that would be helpful to you, but if it doesn't, there isn't a thing the client can do about it.
nintendo64 - Tue Mar 09, 2004 3:20 pm
Post subject:
Yes, it's just putting it in the correct order, also dont believe the names like Ekted said.

for example in VB (the code you have)

Note:
Code: Show/Hide
Public Declare Sub CopyMemoryX Lib "kernel32" Alias "RtlMoveMemory" (Dest As Any, Src As Any, ByVal cb&)


Code: Show/Hide
Public Function StringToLong(ByVal RawText As String) As Long
    Dim L As Long
    Call CopyMemoryX(L, ByVal RawText, 4)
    StringToLong = L
End Function


and in ASM

Code: Show/Hide
function StringToLong(const Str1:String): LongWord;
begin
    asm
    mov         esi, Str1
    mov         eax, dword ptr [esi]
    mov         Result, eax
    end;
end;


Also:
Those names are simply to remind you of Long as in 4 bytes in the packet structure and of integer as in 2 bytes in the packet structure. This is because you have to make each packet structure by each packet that composes it in most high level languages.

Example in VB:

For the encryption request you have to send a

00 01 KK KK KK KK 01 00, but since you cannot do like in C define your own structure, , you have to use Chr().

Code: Show/Hide
erequest
   {
   BYTE  core;
   BYTE  header;
   DWORD key;
   WORD   encrtype;
   }


LongToString, StringToLong, IntegerToString, StringToInteger, just help you fill the places where 2 bytes (WORD) and 4 bytes (DWORD) are present.

You have to send the above packet structure like this.

Code: Show/Hide
Chr(0)+Chr(1)+Longtostring(key)+IntegerToString(1)



-nintendo64
Solo Ace - Tue Mar 09, 2004 8:29 pm
Post subject:
Reading this thread makes me want to kill someone. icon_sad.gif
Qndre - Wed Mar 10, 2004 6:06 am
Post subject:
nintendo64 wrote:
[..]
You have to send the above packet structure like this.

Code: Show/Hide
Chr(0)+Chr(1)+Longtostring(key)+IntegerToString(1)



-nintendo64

So it does the same as my function does:
_
My function
Code: Show/Hide

byte(1) = int(long / 16777216)
long = long - (byte(1) * 16777216)
byte(2) = int(long / 65536)
long = long - (byte(2) * 65536)
byte(3) = int(long / 256)
long = long - (byte(3) * 256)
byte(4) = int(long / 1)
long = long - (byte(4) * 1)
string = chr(byte(4)) + chr(byte(3)) + chr(byte(2)) + chr(byte(1))

_
My software can log in as sysop now, spectate and stay in (if SYSOP). But it doesn't get ANY SMALL POSITION PACKET, yet.
_
So I've got two questions:
1. When does server send LARGE POSITION PACKET (0x05) and when does it send SMALL POSITION PACKET (0x28)?
2. Continuum can follow a specific player (select it from playerlist, then press CTRL) - how can I do this? Is there a specific packet or does Continum just copy the player's position packets like FOLLOWBOT does?
2dragons - Wed Mar 10, 2004 1:05 pm
Post subject:
There is a spectate player packet.

0x08 <player id>

Been awhile since I worked with those packets, but I believe the first is more of a weapons packet. If that is so then when someone fires a weapon, drops a brick, etc...
Mr Ekted - Wed Mar 10, 2004 2:19 pm
Post subject:
0x28 is position packet. 0x05 is a weapons packet, which has all the same info as a position packet plus weapons and other status (and a 2 byte pid and 2 byte bounty).
Qndre - Wed Mar 10, 2004 4:25 pm
Post subject:
k - I'll handle them both. Shouldn't be too much of a problem - just different offsets.
Qndre - Thu Mar 11, 2004 7:52 am
Post subject:
I was looking at this website:

... and I wondered if that is all a big joke because this CAN'T be true. I don't think it would be legal to do that so I think you don't have to demonstrate against a thing which is against the law itself. But I think you are right with this website. They are NOT allowed to do so. It would be full control over the market. But one thing I don't understand is ... if this would become true ... why don't we all use Linux?

They can't make a law which makes competition illegal. But if you are right with that then I'm also against it.
Mr Ekted - Thu Mar 11, 2004 10:24 am
Post subject:
What are you replying to here? icon_smile.gif
CypherJF - Thu Mar 11, 2004 10:39 am
Post subject:
Qndre: don't let this thread become off-topic.
Qndre - Thu Mar 11, 2004 11:14 am
Post subject:
Mr Ekted wrote:
What are you replying to here? icon_smile.gif

I just wondered about this TCPA stuff.

Why shouldn't people use Linux if MS wanted to do such a thing... Because it isn't running on new Intel-CPUs then? So everyone would change to Linux and Intel CPUs would vanish out of the computers if they had such a system installed and these companies wouldn't sell one of their products if they would spy out user's data by manipulating the CPUs and let only MS software run on their systems. So on this site they tell that it would be illegal to sell software which doesn't require the new CPUs and is running on other operating systems and you would spend 5 years in jail if you did so... I don't believe that would be possible because no one would accept such a law. So it's a big joke isn't it?
_
I just said this because you link to this against-TCPA-website in almost every thread you post, Ekted.
Solo Ace - Thu Mar 11, 2004 11:34 am
Post subject:
Probably because... it's part of his signature? icon_rolleyes.gif
Qndre - Thu Mar 11, 2004 1:24 pm
Post subject:
May be the easiest solution - but WHY is it part of his signature? Because it's anti-MS? *i-am-supporting-everything-which-is-anti-ms* biggrin.gif
_
I'll continue development today - large position packet handler...
Qndre - Thu Mar 11, 2004 1:55 pm
Post subject:
Made my client spectate a 800x600 area of the map (the center) and show Players with a label (no graphics yet). Next steps will be: Writing a renderer to render images and show up the correct shipset (without LVL first) and making the bot spectate up to 50 players within the area which it spectates. That will be enough! biggrin.gif After that I'll try to decode the LVL to BMP and look if I can cut out things of it. Then I'll not only render ships but also bullets and bombs. And then I'll write the functions "follow-a-player" and "follow-the-action"! And finally optimize the webserver for it and make it able to generate videostream. So I still have a long way to go but I'm going ahead step by step and I'm not going backwards. biggrin.gif That's important!
Mr Ekted - Thu Mar 11, 2004 3:53 pm
Post subject:
TCPA is not a big joke to them. There is a bill in congress that would make it illegal to operate a computer without TCPA-enabled hardware (cpu, mobo, hard drives, cd/dvd, sound/video boards) and software. It could be the case that files you create with your copy of Word are not viewable using another copy of Word, or another app (eg Open Office), and if you ever lose your "license" to use that copy of Word, then all files you created with that copy are rendered unreadable. You will not be able to rip music/movies into raw media files even for your own use. Does this all sound crazy? It should make you livid. The average person doesn't even know about this stuff, but it's already happening. If you have a creative labs sound board, you already have TCPA hardware ready to start taking over. If you installed WMP9, you already agreed (accepted install license) that it may prevent you from viewing (or even delete) files that it thinks you do not have permission to view. And of course all the TCPA stuff is being done under the guise of making computers resistant to viruses, worms, and trojans, all of which Microsoft's own software (namely Outlook and Internet Explorer) significantly helped to propagate. It's sickening.

As far as what you do next, I feel the most important thing is to have reliability working perfectly. Otherwise receiving position packets and other per-player data is meaningless.
Cyan~Fire - Thu Mar 11, 2004 4:54 pm
Post subject:
>-( Your dumb graphic tried to set a cookie on my computer, Qndre! Grrrr.

Why's your server setting cookies on hosted graphics??
CypherJF - Thu Mar 11, 2004 11:15 pm
Post subject:
Mr Ekted wrote:
TCPA is not a big joke to them. There is a bill in congress that would make it illegal to operate a computer without TCPA-enabled hardware (cpu, mobo, hard drives, cd/dvd, sound/video boards) and software. It could be the case that files you create with your copy of Word are not viewable using another copy of Word, or another app (eg Open Office), and if you ever lose your "license" to use that copy of Word, then all files you created with that copy are rendered unreadable. You will not be able to rip music/movies into raw media files even for your own use. Does this all sound crazy? It should make you livid. The average person doesn't even know about this stuff, but it's already happening. If you have a creative labs sound board, you already have TCPA hardware ready to start taking over. If you installed WMP9, you already agreed (accepted install license) that it may prevent you from viewing (or even delete) files that it thinks you do not have permission to view. And of course all the TCPA stuff is being done under the guise of making computers resistant to viruses, worms, and trojans, all of which Microsoft's own software (namely Outlook and Internet Explorer) significantly helped to propagate. It's sickening.

As far as what you do next, I feel the most important thing is to have reliability working perfectly. Otherwise receiving position packets and other per-player data is meaningless.


I thought the Digital Millenium Act already provides that provision such that OpenOffice or whatnot isn't allowed to open the new MS Office documents because it contains encryption which is property of MS and what not, and any attempt to bypass it makes it illegal....

It'll be a bummer for the computer industry as a whole if such TCPA legislation passes, only showing how stupid congress can get.. they vote on measures, they know nothing of. heh thats my own opinion, and remarks to it probably shouldn't be posted here to make the topic off w/e.. yeah...

keep up the work w/ your app there man...
Qndre - Fri Mar 12, 2004 7:30 am
Post subject:
Mr Ekted wrote:
TCPA is not a big joke to them. There is a bill in congress that would make it illegal to operate a computer without TCPA-enabled hardware ...
As far as what you do next, I feel the most important thing is to have reliability working perfectly. Otherwise receiving position packets and other per-player data is meaningless.

If this would happen I'd use Linux or throw my whole PC into the bin and buy a Macintosh. They can't make other computer systems illegal because you can sell what you want and Microsoft has NO way to decide about other companies. icon_exclaim.gif AND MICROSOFT CAN NOT CHANGE THE LAW!!! icon_exclaim.gif So if company "XYZcomputers" wants to build a system WITHOUT this TCPA then they are allowed to do this because this illusive law which would forbid this can never exist in democracy.
About "Cyan-Fire" who said that my (??) server would place a cookie... It's not my server. I only rent it for free so I get it ad-sponsored and the ad-people place cookies because AD only shows up on every second visit.
[..] But back to the topic. What can be the content of such a reliable packet? Can every packet be sent as reliable?
Quote:

and if you ever lose your "license" to use that copy of Word, then all files you created with that copy are rendered unreadable

Someone WILL crack it. I've heard it uses Triple-DES and the person who told about it said "Someone WILL crack it but it uses Triple-DES. And if Triple-DES is cracked then our computers don't matter any more because then we have a real problem..."
Mr Ekted - Fri Mar 12, 2004 7:56 am
Post subject:
You have to be prepared to handle ANY packet reliably and unreliably. In fact there are packets that are sent both ways. That is why I say reliability is a layer. All incoming packets must go through it. Unreliable packets get sent directly to the application layer, and reliable packets get acked (maybe), buffered (maybe), and queued for the application (maybe).
Mr Ekted - Fri Mar 12, 2004 7:57 am
Post subject:
TCPA is not a Microsoft thing. It will apply to all computers and devices with CPU's in them: Windows, Linux, Mac, cell phones, PDA's, etc.
Qndre - Fri Mar 12, 2004 11:46 am
Post subject:
Mr Ekted wrote:
TCPA is not a Microsoft thing. It will apply to all computers and devices with CPU's in them: Windows, Linux, Mac, cell phones, PDA's, etc.

And if ONE computer producer doesn't support this TCPA thing (which is a spy function) then everyone will use it. And I doubt Microsoft has the power to tell every computer manufacturer what he should use. Maybe it's like this now but if they do THIS THING then people won't buy computers with this TCPA any more. And after some time there will be companies which sell the computers without it. And people will buy these machines.
Mr Ekted wrote:

Unreliable packets get sent directly to the application layer, and reliable packets get acked (maybe), buffered (maybe), and queued for the application (maybe).

What is the difference between buffering a packet and queueing it? And why do I have to handle the packets in the correct order?
_
And I'll say it here again:
I AM AGAINST TCPA
(even if I don't think it will ever happen)

Mr Ekted - Fri Mar 12, 2004 12:59 pm
Post subject:
Think of it like gun control. If you owned a machine gun, and they were suddenly outlawed, then you would be breaking the law to keep it.

Quote:
What is the difference between buffering a packet and queueing it? And why do I have to handle the packets in the correct order?


By buffering I mean storing rather than passing it on. Queuing usually means to store and passon in the order queued. You must handle reliable packets in sequence number order. Say you receive packet 18 for XYZ entering arena, then packet 17 for XYZ leaving arena. If you handle them in the order received, you will think XYZ is not present, and all further packets for things like movement, weapons, text, etc will have no player associated with them. And this is only a simple case.
Qndre - Fri Mar 12, 2004 1:45 pm
Post subject:
That makes sense!
_
IMPORTANT!
For technical discussion please use the thread "Metaspace Client Updates": http://forums.minegoboom.com/viewtopic.php?p=16886#16886
But please read what I expect if I say technical discussion.
For trash-talk about my client you should stay here!

Mine GO BOOM - Sun Mar 14, 2004 6:50 pm
Post subject:
I come back to see this thread alive (5 new pages), only to see it get derailed.

Keep it on track please. If it gets too far off topic, I'll split some posts out.
Mr Ekted - Mon Mar 15, 2004 6:44 am
Post subject:
Actually at this point, I would prefer that Qndre start new threads for specific topics when he has questions, using appropriately descriptive subjects. I'm sure some disregard this thread as a flame war, when they might benefit from some of the dicussion.
Anonymous - Sun Dec 05, 2004 1:46 am
Post subject:
Why in the fuck isn't there a working continuum linux patch.
Solo Ace - Sun Dec 05, 2004 5:22 am
Post subject:
Bump?!
Dr Brain - Sun Dec 05, 2004 9:50 am
Post subject:
Delete these three posts now.
Smithy101 - Sun Dec 05, 2004 11:21 am
Post subject:
OMFG!!! Bumpy Loser

OMG I A 1337 GUEST I BUMP ALOT!!11!
Blindmonkey21 - Sun Dec 05, 2004 11:50 am
Post subject:
^--Wtf?

Oh bad just realized this is my 100th post $$$
Cyan~Fire - Sun Dec 05, 2004 12:18 pm
Post subject:
If you were trying to be sarcastic, smithy, be aware that you did just perfectly describe yourself.
CypherJF - Sun Dec 05, 2004 1:08 pm
Post subject:
i thought MGB would have coded in such a thing where guest's can't bump old topics by now... :sigh:
Mine GO BOOM - Sun Dec 05, 2004 1:22 pm
Post subject:
CypherJF wrote:
i thought MGB would have coded in such a thing where guest's can't bump old topics by now... :sigh:

I'm getting close to. The original reason was so if someone used search to find a question related to theirs, they can bump it, which will help narrow down the new user's problem, since he can pick up where the previous posts were left off.

Its seems though, in non-question threads, once a thread hits 30 days, the only reason it will be bumped is for a pointless post to be tacked on. I might do something about that soon.
Blindmonkey21 - Sun Dec 05, 2004 1:41 pm
Post subject:
MGB you need to get a new Avatar that is one of the worst ones I have seen you use icon_confused.gif
D1st0rt - Sun Dec 05, 2004 1:49 pm
Post subject:
likewise to you, his is cool
Blindmonkey21 - Sun Dec 05, 2004 1:50 pm
Post subject:
Hobbes is cool icon_sad.gif
CypherJF - Sun Dec 05, 2004 1:56 pm
Post subject:
Mine GO BOOM wrote:
[..]


I'm getting close to. The original reason was so if someone used search to find a question related to theirs, they can bump it, which will help narrow down the new user's problem, since he can pick up where the previous posts were left off.

Its seems though, in non-question threads, once a thread hits 30 days, the only reason it will be bumped is for a pointless post to be tacked on. I might do something about that soon.


I would just make it that guest's can't bump threads regardless. If a registered user wants to, then you're able to ban them if they continually do it.
Cyan~Fire - Sun Dec 05, 2004 4:36 pm
Post subject:
Actually, I kinda like MGB's current avatar. Do you actually understand it blind?

Back on topic, I agree with Cyph on this one.
Blindmonkey21 - Sun Dec 05, 2004 5:00 pm
Post subject:
Cyan~Fire wrote:
Actually, I kinda like MGB's current avatar. Do you actually understand it blind?


No, what is it supposed to be?
Dr Brain - Sun Dec 05, 2004 5:35 pm
Post subject:
The probablilty field of an electron in the first P shell of an atom, if memory serves.

Actually, on second look, it's probably the D shell.
Blindmonkey21 - Sun Dec 05, 2004 5:47 pm
Post subject:
Doesn't it go SPD? And why does it keep dissapearing?
Mine GO BOOM - Sun Dec 05, 2004 10:44 pm
Post subject:
Blindmonkey21 wrote:
And why does it keep dissapearing?

Look up about Heisenberg's Uncertainty Principle. Since you didn't like that one, how about this one?
CypherJF - Sun Dec 05, 2004 11:03 pm
Post subject:
That one is cool too icon_smile.gif
Cyan~Fire - Sun Dec 05, 2004 11:49 pm
Post subject:
Darnit. You're going to make my head explode, MGB.
Mine GO BOOM - Mon Dec 06, 2004 1:52 am
Post subject:
Cyan~Fire wrote:
You're going to make my head explode, MGB.

Wait until you try to understand the Copenhagen Interpretation. That ones a good one to twist your mind around.
Blindmonkey21 - Mon Dec 06, 2004 8:34 am
Post subject:
It looks kind of like a 3d electron dot diagram but it is hard to tell because it keeping spinning and dissapearing.
lp_street_soldier - Mon Dec 06, 2004 2:44 pm
Post subject:
lol
D1st0rt - Mon Dec 06, 2004 10:30 pm
Post subject:
sa_tongue.gif I'm still on Lenz's law in physics, I think relativity is next
Smithy101 - Tue Dec 07, 2004 7:09 am
Post subject:
Cyan~Fire wrote:
If you were trying to be sarcastic, smithy, be aware that you did just perfectly describe yourself.


I was.....joking...
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group