madhaha Posted August 21, 2003 Report Posted August 21, 2003 After reading the dialog between Mr. Ekted and Coconut emulator, I have drawn the following conclusions on how we might extend the Continuum client code. I am not a coder however, so please point out any silly flaws in my theory. The only way we can keep the game "secure" is for the client to be programmed closed source. However, extending the code is a breathtakingly slow process which is completely reliant on one Priit Kasesalu as we want to minimize the number of people with the full source. However, would it not be possible to use third party client code in the form of a plugin system if we can validate it serverside? I know it'd be extremely difficult to actually implement but the model itself is quiet simple. We have the server code. We have Priits ultrasecret "core" code that deals with the parts that MUST be closed source. Then we use plugins to sort out the weapons code, rendering, hardware support, handling of media files etc. Collaboration between Priitk?s core code and the server ensure that only the intended plugins are used (no plugin hacking/swapping without authorization serverside!). Thats the theory. Would it be worth bugging Priitk for it and would this system work?
Yupa Posted August 21, 2003 Report Posted August 21, 2003 After reading the dialog between Mr. Ekted and Coconut emulator, I have drawn the following conclusions on how we might extend the Continuum client code. I am not a coder however, so please point out any silly flaws in my theory. The only way we can keep the game "secure" is for the client to be programmed closed source. However, extending the code is a breathtakingly slow process which is completely reliant on one Priit Kasesalu as we want to minimize the number of people with the full source.more like Priit will not give out the source and nobody else wants to play catch up by trying to code their own client or challenge the existing one However, would it not be possible to use third party client code in the form of a plugin system if we can validate it serverside? I know it'd be extremely difficult to actually implement but the model itself is quiet simple. We have the server code. We have Priits ultrasecret "core" code that deals with the parts that MUST be closed source. Then we use plugins to sort out the weapons code, rendering, hardware support, handling of media files etc. Collaboration between Priitk?s core code and the server ensure that only the intended plugins are used (no plugin hacking/swapping without authorization serverside!). Thats the theory. Would it be worth bugging Priitk for it and would this system work? so you want to bug Priit for help with something that will make it so we won't have to bug Priit? ...
Smong Posted August 21, 2003 Report Posted August 21, 2003 What about rogue ops hosting servers with bad plugins? The client downloads the plugin from the server, and then anything could happen.
madhaha Posted August 21, 2003 Author Report Posted August 21, 2003 Well its up to the programmers but its fairly simple to restrict the plugins to operations in the continuum folder only (and not the profiles.dat file naturally) isn't it? Akai: Exactly!
Mr Ekted Posted August 21, 2003 Report Posted August 21, 2003 Allowing user dll's to load into Continuum would be giving access to the process space. Even the menu dll is checked before loading to prevent modification. From a security POV, this would be a very tricky thing to implement.
madhaha Posted August 21, 2003 Author Report Posted August 21, 2003 By tricky do you mean a "impossible" or "I haven't a clue if its possible" type situation? And is it worth giving a shot?
»Admiral Kirk Posted August 21, 2003 Report Posted August 21, 2003 Interesting consideration, Client can check DLL's via servers checksums based on the unhacked client. I like it, and im quite sure its posible, but most probably VERY difficult. It seams doubtfull though that Priit will deam it a worthy cause for his valuable time, as SS seams to rate pretty low on the totem pole lately.
Mr Ekted Posted August 21, 2003 Report Posted August 21, 2003 I haven't thought it thru, but I think what you'd need is some kind of "sandbox" scripting language like java that's "crashproof" and only has access to what it needs. Would need to be a complete custom setup.
orb360 Posted August 21, 2003 Report Posted August 21, 2003 You could just make the client download the un hacked dlls every single time.... or mabye just download the entire game everytime... I like it! I am brilliant! No, but seriously, it's like system security... I can make my system completely secure by turning it off and disconnecting all cabling and dismantleing it... no one could hack that... but it reduces functionality. As soon as I want to turn it on, I open up holes. When my webserver starts, I open holes... If I want to share files, I open holes... There is no way to get around this... As soon as you implement this dll thing, you will open up holes in the security... comes with the territory... the best protection would be allowing the server to run code on the client's machine. then in the middle of a long EULA, put it in text since no one reads that. Then if anyone tries to cheat, you can fix em for good. (dumb idea, I know, but effective...) you could even make all of the other online clients ddos the cheater, or give him a virus, or format his HD, or any other number of 'punishments.' Problem is, absolute power corrupts absolutely, so everyone would abuse this. My solution... there is none... new security updates will come out, new hacks will come out... just got to keep pluggin away.... In this stance I think the dll idea is a good one because it will help speed up the development of continuum.
ExplodyThingy Posted August 22, 2003 Report Posted August 22, 2003 This sounds like ASSS modules.Although, what would prevent a plugin from doing nullifying weapons info or handeling, or even moving the users ship around the weapon?
divine.216 Posted August 22, 2003 Report Posted August 22, 2003 A few thoughts1) If cont is compromised then a checksum can be spoofed anyways2) Without wanting to underestimate peoples creativity, what kinds of things could really be written with a "sandbox" scripting language? how does that measure up with the time and/or security issues?3) ... we're all impressed that you know priitk's full name but why do you refer to him by it? This is still SS yes? You're complaining that priit is not engaging in feedback discussions on new Cont features. It's fun to talk about possible ideas for the client, but don't get too worked up about it; because speculation on new development is a waste of time. Priit comes out with new versions of cont that seem to include features that were intriguing for him to write -- they have almost never reflected public demand (the exception being certain bug fixes: prox bug, pball fire delay etc.) I guess the conclusion I'm drifting towards is that speculation on client development is tempting because of its obvious opportunities, but really almost entirely useless. Speculation on server-side development is much more productive. And who knows, maybe priit really is waiting for ASSS to be used on a large scale before working on larger development -- I look forward to finding out.
numpf Posted August 22, 2003 Report Posted August 22, 2003 first i'd like to request that orb360 never post here again. You remember when you claimed to have some SS AI written but not physics? It's a running joke. Many of you need to remember that continuum is developed is coded in priitk's free time. Also remember that the primary reason continuum was created was security and the fact that twister existed. Opening cont up to arbitrary code in it's process space as ekted said is a security risk. To minimize the risk priitk would have to write a custom interpreter/compiler for a 'sandbox' language as ekted described. That would cost too much time, and there would be the additional security risk of bugs in such an interpreter. All those factors considered, it simply isn't worth as much in terms of priitk's time as many other things would be. Don't expect to see this soon, if ever. -numpf
madhaha Posted August 22, 2003 Author Report Posted August 22, 2003 This sounds like ASSS modules.Although, what would prevent a plugin from doing nullifying weapons info or handeling, or even moving the users ship around the weapon? Nothing, thats the point. The idea is that you could completely rewrite the weapons system to do new things. What can be done with just a sandbox language? Well I was hoping that the system can partly replace the bots in the role of custom game types. For example, the warpto bots could be replaced quiet easily. Also, taking MERC Samurai as an example, you could use the system to create "environmental" effects but without the lag from running the whole show serverside. Also, the benefits of adding hardware support i.e. allowing you to ascribe actions to say mouse clicks on the interface, would open up lots of other options. In response to divine.216, if continuum was compromised then you wouldn't need a plugin system to cheat. The question is if there is a way to write the system without making continuum more vulnerable than it already is. I await coconut emulator's thoughts on this.
Coconut emulator Posted August 22, 2003 Report Posted August 22, 2003 Why don't we pay for a programmer to redo Subspace from scratch and then we sink him with the source into the deep sea? It will be more or less like now. Or we can sue Priit for being a Bin Laden terrorist, this way he will be plenty of free time in Guantanamo. Now serious... The 2 most risky aspects of an online game like SS/Cont are:1. The possibility of gaining access to client program space.2. The possibility of gaining access to decrypted game traffic. madhaha's design has nothing to do with the 2nd risk, but it increases the 1st. madhaha's design can be applied, why not, but, besides it is a lot of work for Priit as everybody said, the risks of letting custom DLLs to access the program space are too high, like Ekted and numpf said. Well... gain access to process space is easy with SoftICE. But we should apply all restrictions available, doesen't matter if they're crackable, in sake of obscurity & obfuscation. Following the madhaha's model, not only SoftICErs and such will have the chance to reverse the code but also programmers with basic knowledge will be able to build custom DLLs to customize the client without the need of reversing, without any knowledge of the !@#$%^&*embly language. It sounds like the prelude of the return of the Twister times or even worse.You want the customizable DLLs to be open-source? Not a single line of the client should be open-source, it is an opinion shared among many of us. Only this reason is enough for me to stop considering it. Talking about gaining access to decrypted game traffic... I think that more than one encryption system should be implemented into Priit "ultrasecret core". The server can switch among all of them in a cyclic way for each client. The server will kick the client connection if it is not using the required encr system. And it will ask for same encr again and again to that particular client on following connections until a successful connection is made. The server can recognize clients using the data actually used by the ban system. What is the advantage of this? The crackers will have to crack EACH AND EVERY encr system... I would give up if I have to crack lets say 3, 4 or 5 encr systems... specially considering the possibility of a new client version with different encr systems comming soon to ruin my bots. Those encr systems can be public ones (DES, PGP, etc) or custom private ones, it really doesen't matter at all. Write custom encryptions is easy, you can easily imagine more than 1,000,000 ways to encrypt. The VIP connection for SS "officially approved" bots can remain as it is now, so "legal" bots won't use the new encr system that I propose so they will still work. Only zone owners can open the door to old bots via the VIP.TXT server file. Coconut emulator
Mr Ekted Posted August 22, 2003 Report Posted August 22, 2003 If the encryption key is 32 bits, and there are 8 encryption systems, then that's the same as a 35 bit encryption key. It would be better to just make a single very complex system with multiple stages and multiple mutation "functions"--something akin to MD5 but 100x larger. It only has to run once to make a table, so it doesn't have to be super fast. But it does have to be large enough that it's prohibitive to reverse.
numpf Posted August 22, 2003 Report Posted August 22, 2003 Why don't we pay for a programmer to redo Subspace from scratch and then we sink him with the source into the deep sea? It will be more or less like now.Except priitk wasn't paid. A critical point that many of you miss. If you (a) really have a big problem with priitk's time restraints, and ( believe you have the sufficient skill to contribute, there is nothing keeping you from rewriting the client from scratch. It really wouldn't be that hard.The 2 most risky aspects of an online game like SS/Cont are: 1. The possibility of gaining access to client program space. 2. The possibility of gaining access to decrypted game traffic. This is somewhat incorrect. If you do things properly (use a proven encryption method and put some obfuscation on top of it) a hacker would need to gain access to code to decrypt and fiddle with game traffic. -numpf
Coconut emulator Posted August 22, 2003 Report Posted August 22, 2003 If the encryption key is 32 bits, and there are 8 encryption systems, then that's the same as a 35 bit encryption key. It would be better to just make a single very complex system with multiple stages and multiple mutation "functions"--something akin to MD5 but 100x larger. It only has to run once to make a table, so it doesn't have to be super fast. But it does have to be large enough that it's prohibitive to reverse.I disagree. 8 encr systems of 32 bit keys each one are not the same as 1 encr system of 32x8 bit keys. The key is just a piece of data. Using keys of 1 MB long won't make it more secure. Cracking the encr is cracking its code. They are 8 encr systems to crack instead of a single one. Maybe is that my english sucks... I will try to put it more clear. The 8 encr systems that you mention aren't used at same time, only one of them is required by server for each whole game session. If you want to develope a bot for Continuum you will have to deal with the 8 systems, cracking them one by one. Right now we only have to crack the only existing encr method.I've heard things like the actual encr is uncrackable, that you need a custom virtual machine to access Priit core. All I can say is that the actual encr system takes 5 times more to be cracked than the old SS one, but, I do insist, it is STILL crackable. Why don't we pay for a programmer to redo Subspace from scratch and then we sink him with the source into the deep sea? It will be more or less like now.Except priitk wasn't paid. A critical point that many of you miss. If you (a) really have a big problem with priitk's time restraints, and ( believe you have the sufficient skill to contribute, there is nothing keeping you from rewriting the client from scratch. It really wouldn't be that hard.The 2 most risky aspects of an online game like SS/Cont are: 1. The possibility of gaining access to client program space. 2. The possibility of gaining access to decrypted game traffic. This is somewhat incorrect. If you do things properly (use a proven encryption method and put some obfuscation on top of it) a hacker would need to gain access to code to decrypt and fiddle with game traffic. I feel like rewriting it all yeah. The thing is... will all of you people accept a new Continuum (lets say I would call it Infinituum or some other stupid latin word like this) comming from a guy who is not Priit? And about the 2 risks, I don't think I'm wrong. Explain these things with few words leads to confusion. Of course gain access to process space is the first thing to do, but it is QUITE EASY with SoftICE and a previouly cracked client (with SoftICE detections removed and code checksum properly tweaked if necessary). When I talk about gaining access to decrypted traffic I don't pretend that access to happen into the memory process space when packets arrive to client, but outside the client (bots or custom proxies which can decrypt/tweak/reencrypt traffic). So, process space and game traffic are different things. Is it clear now?
numpf Posted August 22, 2003 Report Posted August 22, 2003 The security of the custom encryption in continuum is that you MUST crack the binary AND find the encryption within it to have any hope of decrypting the packet stream. !@#$%^&*uming good protection of the binary, if you can find and decipher the encryption in it you may as well just modify the client to cheat. -numpf
Coconut emulator Posted August 22, 2003 Report Posted August 22, 2003 The security of the custom encryption in continuum is that you MUST crack the binary AND find the encryption within it to have any hope of decrypting the packet stream. !@#$%^&*uming good protection of the binary, if you can find and decipher the encryption in it you may as well just modify the client to cheat. Exactly. That's why if we are talking about ripping the encr (or talking about cheating as well) we are talking about accessing process space as the fisrt step to be taken. Once this is done and encr is already extracted you can write a Continuum specific proxy to access the traffic outside the client, which is a different thing related to the security of the game than accessing the process space. We have to distinguish between accessing traffic into memory space or outside the client. They must be considered 2 different risks.
madhaha Posted August 22, 2003 Author Report Posted August 22, 2003 So let me get this straight: We can carry on as we also have done with snail paced development. If we lose contact with Priitk then we're dead in the water. We can try the plugin route and if it works as its meant to then we have collaborative development but if Priitk makes a mistake then it would mean a return to widespread cheating (would it also render clients we are using now obsolete?) OR SOMEONE codes us a new client, possibly even a new protocol. -*BAD WORD*-, the poor -*BAD WORD*-(s) would have to clone the game from scratch!
numpf Posted August 22, 2003 Report Posted August 22, 2003 you have 2 choices, not 3. plugins would require priitks cooperation which you shouldn't expect and wont get. -numpf
Coconut emulator Posted August 22, 2003 Report Posted August 22, 2003 We can carry on as we also have done with snail paced development. If we lose contact with Priitk then we're dead in the water. We can try the plugin route and if it works as its meant to then we have collaborative development but if Priitk makes a mistake then it would mean a return to widespread cheating (would it also render clients we are using now obsolete?) OR SOMEONE codes us a new client, possibly even a new protocol. -*BAD WORD*-, the poor -*BAD WORD*-(s) would have to clone the game from scratch!you have 2 choices, not 3. plugins would require priitks cooperation which you shouldn't expect and wont get. Yes, the thing is like you both madhaha and numpf says on your last posts, in my opinion. If you think the game will resist a half-open-source client then your design is pretty good for the fast evolution of the game that you are looking for, madhaha. The other way is rewriting it all *sigh* from scratch. But, as numpf stated above, the custom DLLs solution requires Priit colaboration, and LOTS of it. A little help having to rewrite it all from scratch will be very appreciated too but we can't expect that from Priit (I'm not insulting Priit, he did a pretty good job saving Subspace without getting paid for it, he don't owe us anything, we owe him QUITE A LOT). Also, I think it will be hard to put the team to work (with the minimum coordination required) on that 3rd party software. If anyone is going to lead that team he must be the one who is already the leader: Mr Ekted of course. Lets see what he thinks of it all after meditation. Also, the possibility of different versions of the custom DLLs competing with others is not a good future for the game, it is my humble opinion.
madhaha Posted August 22, 2003 Author Report Posted August 22, 2003 you have 2 choices, not 3. plugins would require priitks cooperation which you shouldn't expect and wont get. -numpf Live in hope. I've just remembered a good anology of the system I propose: UnrealTournament's mutator system. This seems to support the idea that the model is workable if there is support on behalf of priitk but I again I can't comment on the security implications. Another question: if Priitk would agree to code this or release the code to a trusted individual in exchange for money, would people be willing to donate?
»SOS Posted August 22, 2003 Report Posted August 22, 2003 If I wasn't a dirt poor Estonian student, probably yes If people can raise money for keeping big server up, surely if some big campaign was ran, enough money could be put together to get PriitK interested in selling the source. (Can't pay him just for plugin system, he could just do some half-!@#$%^&*ed crap)
Coconut emulator Posted August 22, 2003 Report Posted August 22, 2003 LOL!!! madhaha!!!! ARE YOU PRIIT?????? MUAHAHAHA
Recommended Posts