PinkyAndThaBrain Posted August 27, 2003 Report Posted August 27, 2003 I have no idea what you mean by perfect physics But you couldnt do anything with the client source code (on an official server) without hacking the encryption and security mechanisms, so point 1 isnt really distinct from point 2. Just a potential consequence. IMO the major problem with hacked clients has been obviousness. As long as there is no obvious cheating there is no problem. I mean you have to be naive to assume that noone is abusing the kind of packet cheats which have been possible for 7+ years (some by abusing inherent limitations placed on the game by being client authorative and because it has to allow some lag, some by design flaws in the protocol which were never fixed). The complete conviction of cheating going on has had an effect on my priorities ... Id rather have the client develop faster than more obscurity. If you put in memory patching abilities in the security code you should be able to combat any blatant cheaters at very short notice without needing to update the client (nearly impossible to sand box something like that).
Mr Ekted Posted August 27, 2003 Report Posted August 27, 2003 Encryption/decryption are required at both ends of the connection. It is not important if encr/decr are taking place into the process space of the server/client or not. It doesn't matter who and how is generating the keystream. It is a fact that the traffic get encrypted before leaving the server and get decrypted when arrives to the client (and viceversa) no matter how it all is done. I thought you were done reading this board. If not, why make a meaningless post like this?
Mr Ekted Posted August 27, 2003 Report Posted August 27, 2003 You dont need to give out the security library at ALL. If you can find client developers who are a little less up tight about open source development and are willing to accept patches all you need to do to allow third party contribution to the client is to release the source code with a nullsecurity.lib/a for instance. This would remove the security mechanisms and only allow you to play on servers which have you in their VIP list, just like open source bots. Audited patches deemed worthy could go into the client. The only clients which could play on the real server would be the ones compiled with realsecurity.lib/a by the central developers for instance. (Personally I would do it with class libraries ... using classes with operator overloading as types for sensitive variables would allow a much nicer abstraction of data protection mechanisms.) It's obvious you are not listening to me. I keep on telling you why doing X is bad, and you keep on saying "Hey! Why don't we do X!"
madhaha Posted August 27, 2003 Author Report Posted August 27, 2003 X is bad, but I think I can live with it. I think X can remove lots of "problems we are having with Y." Is what he's saying.
Dr Brain Posted August 27, 2003 Report Posted August 27, 2003 It will never happen. Who cares if we could live with it?
PinkyAndThaBrain Posted August 27, 2003 Report Posted August 27, 2003 It's obvious you are not listening to me. I keep on telling you why doing X is bad, and you keep on saying "Hey! Why don't we do X!"What I am saying is not "Why don't we do X!" it is "Why don't we do !X". You do not say the situation I propose is bad. Anything *can* be done. Not true for the situation I propose. allowing players to modify ANY part of the clientNot true for clients compiled with the closed security code, what goes into those clients is at the complete discretion of the central developers. Giving out source code plus a security library means undoing almost ALL of Cont's protection. I can see no reasonable way in which you can construe that I am suggesting this be done.
Dr Brain Posted August 27, 2003 Report Posted August 27, 2003 Giving out source code plus a security library means undoing almost ALL of Cont's protection. I can see no reasonable way in which you can construe that I am suggesting this be done. Releasing the majority of the code removes the obscureification of the client, allowing memory modification cheats. You need to remember that there are more security methods present than just packet encryption
PinkyAndThaBrain Posted August 27, 2003 Report Posted August 27, 2003 Be that as it may, releasing the source code without the security library != releasing the source code plus security library. Do you really think I would forget other forms of security, given that I already suggested using class based types for sensitive variables to provide a way to easily abstract the security mechanisms earlier in the discussion?
»CypherJF Posted August 28, 2003 Report Posted August 28, 2003 Get as many freshman college students addicted to subspace as you can (preferably EE students) and hope for a miracle. i tried telling em about it... but no one listens to cypher they're all addicted to freaking X Box and Unreal Tourney... >: ( - cypher
Coconut emulator Posted August 28, 2003 Report Posted August 28, 2003 Encryption/decryption are required at both ends of the connection. It is not important if encr/decr are taking place into the process space of the server/client or not. It doesn't matter who and how is generating the keystream. It is a fact that the traffic get encrypted before leaving the server and get decrypted when arrives to the client (and viceversa) no matter how it all is done. I thought you were done reading this board. If not, why make a meaningless post like this? Once again, your wrong, Ekted. I'm NOT leaving this forum. Muahaha. I will leave when I want, if you don't mind. Meaningless is not the word. English is not my main lang (neither !@#$%^&*embly is yours), but the word "obvious" seems to fit better in your phrase.Well, if you don't understand the meaning of it I can explain it in more detail. I said that obvious (not meaningless) thing because you and SOS were talking as if the encryption is "floating in the air", it is not present on server code, it is useless to extract stuff from the client... You were talking as if it enhance security some way. It adds some obscurity, I couldn't call it obscurity, it is just twilight. Who cares about who is generating the keystream, in which space the routines run, how it is wrapped. Who cares about all of that if it is still crackable in the end?The conversation between you and SOS is good as a disinformation campaign but if you think that the encr can not be ripped from a full zone running at home... maybe the word "lost" is the one to define you.
Mr Ekted Posted August 28, 2003 Report Posted August 28, 2003 We were discussing Smong's question about including ASSS encryption, which is going to be open source, in a client. And SOS and I were telling him that the encryption algorithm does not exist in the server. We are not currently discussing the concept, as you seem to be dwelling on, that the entire game of Subspace is so incredibly insecure that we might as well pack it up. No one agrees with you, except maybe Gravitron, and we have learned to ignore him as well. Yes, given enough time, anything can be cracked. That doesn't mean it will be cracked. That doesn't mean we should stop playing.
PinkyAndThaBrain Posted August 28, 2003 Report Posted August 28, 2003 Which is exactly my arguement Everything can be broken, so wether giving up a little security is worth it is entirely a matter of opinion. Keeping the security code back and only having it compiled into official clients still provides security. It does not allow players to do anything, it does not allow players to modify any part of their client (at least not the ones they can play with on official servers) and it in and of itself does not allow them to load code into Continuum memory space to observe how the security mechanisms work (since the security mechanisms arent there to observe). It just makes the security code a little easier to isolate in official clients. You can offset that by updating the client more often. Oh BTW, it took me all of 2 hours to load code into the Continuum memory space ... and I am a sucky coder. Security by obscurity might work, but security by blind faith in the inability of others doesnt.
Coconut emulator Posted August 28, 2003 Report Posted August 28, 2003 It is already cracked. I'm not going to harm the game, as I said before. But it is ALL cracked, be sure of it. Do you think I'm trying to stop people from playing? And do you think nobody agree with me? On what questions? About greens maybe? So, nobody agree with me in a single thing... *laugh*
Mr Ekted Posted August 28, 2003 Report Posted August 28, 2003 Ok let's take this discussion in a new direction. Instead of talking about why everything in Continuum is insecure and wrong, let's talk about the way it should work. What do you do to make a client secure if it needs to be significantly authoritative? If you don't think the client has to be, then explain how, for example, movement can be completely handled by the server but still provide smooth play for the user. Ignore Subspace; imagine you are building a new multi-player fast-action game from scratch.
Coconut emulator Posted August 28, 2003 Report Posted August 28, 2003 Well... at least we agree on 1 thing: this converstaion is out of control. I don't know much of you, but I understand that you are a good at programming. You "only" made the menu of Continuum but I'm sure you are able to code those parts that Priit preferred to keep on his own, for the sake of obscurity. I agree on almost everything... 100% closed source for the client... server-authoritative model for most things... no plugins at client side... etc. You don't know much of me but it seems like you decided I just "don't exist". We can rant forever about that... I give up, it makes no sense and I feel even more stupid than I am. I'm not using irony when I say I wish you good luck with Continuum and all your projects, Ekted. I'm not pretending everything is wrong in Continuum. It is a pretty good piece of software.Very few things, like greens, should be passed from client to server. I know (I supose) Priit could have designed a much better greening system without having to maintain compatibility with Subspace protocol and client.Encryption system can be enhanced, to make it even harder to crack, it is one of my "strong" points. The amount of code to be cracked/ripped/hacked/stealed is very important when extracting Continuum encryption. The more code the more nightmare you get, I swear. Putting 8 encryptions in the "core" will make me give up. I think on solutions that will make give up to people like me. I don't think I'm a genious, NASA didn't call me yet I know to crack thingies, that's all. I have some skill after 12 years cracking all kind of stuff. Encryption has to be fast, so I can't think on adding lots of code that could downgrade the perfomance of the client. Also, it can't be very simple (few code) because it makes it easier to crack. Just add more than 1 encr system, and make the server/client to be able to switch between them on a per-session basis. I'm already extracting physics and considering those parts of the protocol that I didn't go through by myself. I can extract physics and lots of stuff from Subspace... how about that It is exactly as Continuum... hmmm or is it the opposite? To extract/review the protocol I just use a custom proxy running a zone at home. Only one thing will stop me from rewriting it: Priit deciding to develope the game as it deserves. Now I expect you to say that I'm not able to code it all... alright. Think what you want.
Coconut emulator Posted August 28, 2003 Report Posted August 28, 2003 About "secure movement"... we agreed on another topic in this forum that secure movement (server driven) is silly and will make the game unplayable.
PinkyAndThaBrain Posted August 28, 2003 Report Posted August 28, 2003 It makes the game unplayable with high lag, but how well would it do in Subspace with say league lag limits? (With a redundancy scheme for C2S communication, say a simular tripple redundancy as Quake had.) Has anyone experimented with this?
madhaha Posted August 28, 2003 Author Report Posted August 28, 2003 How would you set up a test rig for that? Any way to do it via server settings or playing around with ASSS?
PinkyAndThaBrain Posted August 28, 2003 Report Posted August 28, 2003 No, you would need to code a new client and server. Or you could hack subspace physics into a top-down view mod for a FPS (most FPSs are mostly server authorative, with HL being a prominent exception).
madhaha Posted August 29, 2003 Author Report Posted August 29, 2003 Could someone hack Snrrrubspace to do it seeing as we have the source availible and its not being put to any other use...
PinkyAndThaBrain Posted August 29, 2003 Report Posted August 29, 2003 It is not a trivial excercise, you would also need to code a server which handled subspace physics.
mister manners Posted August 29, 2003 Report Posted August 29, 2003 aside all of this, he should make it, so you can read all of the waeapos code, and ship code, and all that -*BAD WORD*-, hey, even the physics, -*BAD WORD*-, gove them the whole code, i dont care, but develop a system to allow ppl to creat and modify, and :0... trade the plugins, and not all game plugins r .dll , he should pnly make it so that if you have a 99 ship plugin with "L999" guns and bombs, that the server would reject it if it is , now this is definable in the server cfg, on the server machine, a world-wide enabled plugin, priit would have it as a dl addon, so you dont have to add a whole new ver of ctnm, and thats all about .dlls!, but the encryption, i dont know much, but i know there is a method of moving your mouse around aimlessly in a box, to create, get this, 1000 bit encryption, it is used in hush mail, an internet mailing account...
mister manners Posted August 29, 2003 Report Posted August 29, 2003 oh, and code a thingy into the server, so you can manually set up to 100 green psitions (512,536 435,763) and all
madhaha Posted August 29, 2003 Author Report Posted August 29, 2003 Troll? Or is this someone trying to be helpful?
Recommended Posts