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.) |
50% Packetloss wrote: |
"The page cannot be found"==the links to your bot's source/binaries plody |
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? |
Quote: |
I doubt it has the needed system calls to even do UDP packets, but that is just a guess. |
Quote: |
Running a plugin on an ASSS server (which no 'large' zone uses yet). |
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). |
ExplodyThingy wrote: |
No one here has yet cracked it, and the author/creator whatever will not release it. |
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. |
ExplodyThingy wrote: |
Continuum uses an enhancement of the VIE alg. |
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. |
Quote: |
we all know essentially how it functions |
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: |
You miserable fuck. Looks like youre smarter than me, and know more about what youre doing. |
Smong wrote: |
And anyone writing encryption wouldn't do a simple XOR, they would throw some other tweaks in there as well.
|
nintendo64 wrote: |
INote the 00 01 Core Packet.
0000 00 01 4F DA 77 97 11 00 ..O.w... |
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° |
Quote: |
even packet headers are encrypted |
Quote: |
open sourced everywhere |
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. |
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. |
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. |
Mine GO BOOM wrote: |
There is only one emoticon in which can express what I feel when I'm reading this thread:
|
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? |
Illetni wrote: |
ya know the lvz file format?? |
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 |
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. |
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. |
ExplodyThingy wrote: |
Try simply sending a chat message, or a drop-koth. Later you can try faking a ship, then requesting the flag. |
Anonymous wrote: |
The server wants timestamps. How do I generate one? |
Mine GO BOOM wrote: |
Once you send the your clock (in C, it would be GetTickCount() / 10), you then send your login packet. |
Smong wrote: |
There is an 0x05 sync packet that includes the packets sent/received, is that what you meant about ping? |
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... |
Quote: |
0000 00 01 4F DA 77 97 11 00 ..O.w... |
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. |
Cyan~Fire wrote: |
Uhh that's instructions on using it an MFC app, which isn't necessarily all about it.
The real GetTickCount() documentation. |
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). |
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. |
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. |
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. |
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"!! |
nintendo64 wrote: |
[..]
Note: I know Continuum is packed, because i've got an unpacked version of it. |
Dr Brain wrote: |
There is code in it to unpack it. |
ExplodyThingy wrote: |
Where exactly did you get (or think you got) ahold of the subspace source? |
Quote: |
You won't crack the Continuum encryption so forget about it [...] |
Quote: |
Snrrubspace |
Qndre wrote: |
I downloaded Snrrubspace to run it on my linux-pc but there is no executable file. What to do?? |
Jason wrote: |
[..] with your ignorant persistence. |
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. |
WarFan wrote: |
...woopdifuckindoo |
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. |
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. |
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. |
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. |
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. |
Cyan~Fire wrote: |
You know, since Ekted is posting in here, you should probably stfu about cracking Continuum encryption, Qndre. |
Code: Show/Hide ... decryptPacket ... |
ExplodyThingy wrote: |
Are you saying that the really gifted dont have enough self control? |
Cyan~Fire wrote: |
you don't actually seem to understand what MD5 does |
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. |
Qndre wrote: |
"that's not right - every MD5 is unique" |
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. |
Mine GO BOOM wrote: |
you should know that decompiling a program is illegal to do in the business world |
Mine GO BOOM wrote: |
The Continuum server? I'm assuming you mean ASSS. |
Mine GO BOOM wrote: |
as long as we don't ever make a cent off it, they don't care |
Nintendo64 wrote: |
Continuum encryption has been cracked in the past |
Qndre wrote: |
No. I mean Subgame2. |
nintendo64 wrote: |
I will say this much, Continuum encryption has been cracked in the past (versions 0.35, 0.36 and 0.37)... |
Mr Ekted wrote: |
Your friend did not make a full Continuum client. |
D1st0rt wrote: |
he was referring to the one Qndre said wrote a full continuum client |
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. |
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. |
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. |
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. |
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 wrote: |
[..]
it can't be illegal to look at the source of Subspace because it is OPEN SOURCE!!!! |
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.... |
Quote: |
none of us has cracked it yet |
Qndre wrote: |
It's open-source because Snrrrubspace is open source and Snrrrubspace is equal to Subspace. |
Qndre wrote: | ||
About Continuum encryption which
|
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. |
Qndre wrote: |
It's a very very very very very very simple encryption. |
Quote: |
ASSS - Open source, from scratch, server software in which Grelminar did. |
Nintendo64 wrote: |
So basicly because OpenOffice opens up files with *.doc extension, it means Microsoft Office is open source too? |
Mr Ekted wrote: |
Qndre, you are a very confused person. [..] |
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. |
Code: Show/Hide int main (int argc, char *argv[])
{ return 0; } |
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. [..] |
Mr Ekted wrote: |
Please lock this thread now. |
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...
|
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. |
Mine GO BOOM wrote: |
I'm sorry to shoot down your idea, as it is a good one |
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."! |
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. |
Quote: |
// SS = 1, Ctm .36 = 16, Ctm .37 = 17 |
Code: Show/Hide temp = (uint32)((uint64)((uint64)key * (uint64)0x834E0B5F) >> 48) + (temp >> 31); key = ((key % 0x1F31D) * 16807) - (temp * 2836) + 123; |
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; } |
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. |
Quote: |
not to abuse ?help command |
Qndre wrote: |
Continuum Decryption: (found on an I-AM-SUBSPACE-ADDICTED-WEBSITE)
Look at the comment. It's not only Subspace but Continuum: Quote: |
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. |
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. |
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. |
Mr Ekted wrote: |
[..] The client decides on the encryption key. [..]
|
Code: Show/Hide 10010101 XOR 11111111 = 01101010 |
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. |
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. |
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). |
Code: Show/Hide Bitstream: 100101110010010100010101011110010101000101001111 Keystream: 110100101010101011001100101001111101001010101010 Key: 11010010101010101100110010100111 |
Quote: |
int(rnd*65535) |
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. |
Quote: |
The Cont keystream generator is probably > 1000 lines of C |
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* |
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. |
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? |
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. |
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 ... |
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? |
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? |
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"? |
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. |
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. |
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. |
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. |
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. |
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 |
Mr Ekted wrote: |
MGB is far from being a competent programmer in my opinion [..] |
Mr Ekted wrote: |
but he's way above you. |
Mr Ekted wrote: |
PriitK and I are the only ones who worked on Cont. There are no other Cont-compatible clients. |
Mr Ekted wrote: |
Then your knowledge is wrong. |
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. |
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. |
Mr Ekted wrote: |
The other was a trojan/browser flaw that uploaded profile.dat. This file used to contain passwords associated with your logins. |
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 [..] |
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. |
Mr Ekted wrote: |
Cont is closed-source. Period. Snrrrub wrote his client from scratch, and it is a VIE client. |
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. |
Mine GO BOOM wrote: |
My code works, but barely. [..] |
Mine GO BOOM wrote: |
[..] but trust me [..] |
Quote: |
Never trust a person who says "trust me". |
Mine GO BOOM wrote: |
My only comment is Shanky gets way too much credit because of my Server Help site. |
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. |
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 |
Mine GO BOOM wrote: |
Seen the Matrix? |
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. |
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. |
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... |
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. |
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) |
CypherJF wrote: |
Did Qndre say Snrrrub space is open-source? If so, is there a site with it on there for download? |
CypherJF wrote: |
Does it essentially come down to, people do not have < insert time/patience/money/resources/any/both/etc > to complete it?
|
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). |
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? |
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. |
Quote: |
0x0005 Core 0x4450E2 Sync Request |
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: |
0x0005 Core 0x4450E2 Sync Request
|
Mr Ekted wrote: |
It's an incorrect comment. |
Code: Show/Hide 00 05 rr rr rr rr |
Code: Show/Hide 00 06 rr rr rr rr cc cc cc cc |
Mr Ekted wrote: | ||
S2C spoof packet is:
Client should reply:
where cccccccc is client time. I assume you know that all fields in SS protocol are Intel order. |
Qndre wrote: |
But what does "Intel order" mean? |
Dr Brain wrote: |
Someone lock this thread NOW. |
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. |
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. |
Code: Show/Hide chr(0) + chr(0) + chr(0) + chr(1) |
Code: Show/Hide 00 01 56 34 12 ff 01 00 |
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:
|
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. |
Code: Show/Hide BYTE mode = getByte(msg, 1);
Uint16 width = getShort(msg, 2); Uint16 height = getShort(msg, 4); Uint32 duration = getLong(msg, 6); |
CypherJF wrote: |
I mean even at Penn State |
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? |
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); } |
Quote: |
Why do you say C looks like junk to you when you can read that? It's almost exactly C. |
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. |
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; |
Quote: |
error C2448: '<unknown>' |
Qndre wrote: |
The output is 200 |
Qndre wrote: |
error C2448: '<unknown>'
|
Mr Ekted wrote: |
[..]
Why not call GetTickCount() inside your VB directly? And why for the love of god are you using MFC? |
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; } |
Code: Show/Hide Private Declare Function GetTickCount Lib "Kernel32" () As Long |
Quote: |
Do you know why the output is 0x200? |
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. |
Qndre wrote: |
No. Not experienced enough. |
Mr Ekted wrote: |
You are doing something wrong. |
Code: Show/Hide 0000 0000|0000 0010|0000 0000|0000 0001 ^ 3 bytes ^ 2 bytes ^ 1 byte |
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. |
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? |
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. |
Code: Show/Hide long myTime; while (true) { myTime++; } |
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. |
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 ... |
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. |
Qndre wrote: |
Why should it me pointless for POLITICAL reasons??? Don't understand... |
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. |
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. |
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. |
Anonymous wrote: |
[..]
And then on the 401st day your work would be worthless. |
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. |
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? |
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 |
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. |
Qndre wrote: |
1. You said the encryption would be about 1,000 lines in C. Re-writing this would take months. |
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? |
Qndre wrote: |
Sorry if that was a bit impolite but if no one gets it. |
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. |
Qndre wrote: |
But I've said "I want to write it for VIE encryption" about five times and you didn't get it. |
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? |
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? |
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. |
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. |
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. |
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. |
Mr Ekted wrote: |
If you run your own subgame you can set it to allow no encryption. |
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. |
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. |
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. |
Mr Ekted wrote: |
Regardless, make your client a sysop, so there will be fewer things that will get you booted. |
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. |
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. |
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 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. |
Code: Show/Hide S 00 05 12 34 56 78
C 00 06 12 34 56 78 tt tt tt tt |
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? |
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 wrote: |
You don't have to post source code here that we all have access to unless you have a question about it. |
ExplodyThingy wrote: |
Thats code from LogicBot isnt it? |
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 |
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 [..] |
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. |
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. |
Qndre wrote: |
[..]
Maybe I can use Snrrub's encryption module and make a DLL out of it I can call in my main application. |
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 |
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 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 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 [..] |
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. |
Mr Ekted wrote: |
It's been 29 days, and so far you've managed to send 2 correct packets... |
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. |
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. |
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. |
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. |
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; [..] |
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: |
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. |
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. |
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. |
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 |
Quote: |
for(uint32 cnt = 0; cnt < 22; cnt++) checksum ^= thePacket[cnt]; |
Code: Show/Hide checksum = 0 for i = 1 to 22 checksum = checksum xor asc(mid(packet, i, 1)) next i |
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 wrote: |
if you have all three active try your "trick" and see if it works |
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) |
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. |
Code: Show/Hide pkt[11] = 0;
for (i = 0; i < 22; i++) checksum ^= pkt[i]; pkt[11] = checksum; |
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. |
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 |
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.
|
Qndre wrote: |
after I have completed the security checksums algorithm. |
Qndre wrote: |
Is it the 4-byte-ACK-ID? |
-Smong- wrote: |
Ekted, how big is the ack 'window'? Does it vary in size according to latency? If so, what is the formula? |
Cyan~Fire wrote: |
I take back almost all of my harsh words earlier. |
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. |
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. |
wEaViL wrote: |
Ok..... Seems to me hes getting somewhere with it.... |
wEaViL wrote: |
I [..] was just saying that Mr Ekted is being a jerk. |
Code: Show/Hide Dictionary.com Jerk is: Slang. A foolish, rude, or contemptible person |
wEaViL wrote: |
was just saying that Mr Ekted is being a jerk |
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 |
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. |
Code: Show/Hide struct PktConnect
{ BYTE type1; BYTE type2; DWORD key; }; |
Code: Show/Hide #pragma pack(1) |
Mr Ekted wrote: | ||
Create a structure that defines the packet and set its members. Such as...
The only trick is to force packing. In VC you would use:
|
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 |
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. |
Code: Show/Hide mov [addr], 12345678 |
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 |
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) |
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 |
Code: Show/Hide function StringToLong(const Str1:String): LongWord;
begin asm mov esi, Str1 mov eax, dword ptr [esi] mov Result, eax end; end; |
Code: Show/Hide erequest
{ BYTE core; BYTE header; DWORD key; WORD encrtype; } |
Code: Show/Hide Chr(0)+Chr(1)+Longtostring(key)+IntegerToString(1) |
nintendo64 wrote: | |
[..]
You have to send the above packet structure like this.
-nintendo64 |
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)) |
Mr Ekted wrote: |
What are you replying to here? |
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. |
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. |
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 |
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. |
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). |
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? |
CypherJF wrote: |
i thought MGB would have coded in such a thing where guest's can't bump old topics by now... :sigh: |
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. |
Cyan~Fire wrote: |
Actually, I kinda like MGB's current avatar. Do you actually understand it blind? |
Blindmonkey21 wrote: |
And why does it keep dissapearing? |
Cyan~Fire wrote: |
You're going to make my head explode, MGB. |
Cyan~Fire wrote: |
If you were trying to be sarcastic, smithy, be aware that you did just perfectly describe yourself. |