»SOS Posted August 24, 2003 Report Posted August 24, 2003 But who would stop people from spreading a virus or a trojan in the plugins?.Net has security measures for these kinds of things, but Continuum not .Net .net has a built in virus scanner? sounds efficient. Not exactly a virus scanner, but you can restrict what code can do (file access, registry, calling native DLLs, etc)
PinkyAndThaBrain Posted August 25, 2003 Report Posted August 25, 2003 Carmack has put back doors in his code and is entirely unapologetic about it ... I see really no reason to trust PriitK and Ekted more than some mod author, I know neither. If someone put a lot of time into making a good enough mod to get a trustworthy server operator to run it then Ill have as much faith in the mod as in Continuum (which is to say not a whole lot, but in general I dont care about security much). Unreal engine games are very nice examples of scripted games BTW. To turn Subspace into something like that would require a complete rewrite though. Personally I like how ASSS does it, abstract the protection mechanisms and open source the rest... the client is a little different in that you couldnt distribute the protection mechanisms themselves. For development of the client you could include a library for simple unencrypted traffic and all integrity checks would just be empty functions (you could only test on your own server where you would specifically allow those clients to connect). The final authority for code going into Continuum would remain where it has always been.
madhaha Posted August 25, 2003 Author Report Posted August 25, 2003 Good summary. Now how to get the rewrite?
PinkyAndThaBrain Posted August 25, 2003 Report Posted August 25, 2003 Get as many freshman college students addicted to subspace as you can (preferably EE students) and hope for a miracle.
Coconut emulator Posted August 26, 2003 Report Posted August 26, 2003 This is -*BAD WORD*-ed up. This development board is dead. Nothing to develope. Priit seems to be the only person in the world who knows something about security and 2D rendering, at least that's what it seems if we have to attend Mr Ekted opinion. I'm afraid to say Mr Ekted doesn't know the game very well in all those technical internal aspects we were talking in here. Discovering how bad is the greening system at 2003 is not a good thing for someone who is leading the game. Saying that 8 encr systems with 32 bit keys are hard to crack as 1 encr system of 8x32 bit keys means he doesn't know -*BAD WORD*- about hacking encryptions. He is the authority because he made the menu of Continuum. And Priit did rewrite the game so Trench can keep on running, that's all. If somebody is planning to write a new game similar to SS he should start his own forum and development team and forget about Priit and Ekted, forget about Continuum and SSC. If he does a good job it is only a matter of time to get new zones running or to get old SS/Cont zones moving to the new game. I really don't know how it can be done on the legal side. I don't know if still VIE or JeffP or PriitK owns the rights. It depends on which country we are talking about. I think it is abandoneware in USA, right? I don't think making a team of students will help. Computer projects are hard to coordinate. An international team won't help. It will be like an orchestra with 10 directors and 1 musician. It has to be a sort of personal project like it was to Jeff and Priit, with some extra collaboration, as Mr Ekted did. So, there is no use to keep on talking on SS/Cont forums. Good luck everybody.
PoLiX Posted August 26, 2003 Report Posted August 26, 2003 Coco seems to have realized most the things every ss player who actually looks beyond the game has realized.
PinkyAndThaBrain Posted August 26, 2003 Report Posted August 26, 2003 That is unnecesarily adversarial. Mr Ekted seems like a reasonable person, whatever you think about his knowledge, and PriitK seems like a person who doesnt care one way or the other what anyone else does. I doubt Mr Ekted likes Grelminar's choice of development model for ASSS but he supports it nonetheless. Pretty silly to talk about copyrights, neither Mr. Ekted or PriitK have ever !@#$%^&*erted inherent rights to dominance of development of Subspace ... their right comes simply from standing up and providing Continuum, if you or anyone else wants to better them just do so (-*BAD WORD*- Im sure if you produced a credible project you could even get a forum on here, seeing that someone like Polix mostly agrees with you). College students tend to have a lot of time on their hand, all you need is a decent coder with lots of time on their hands and some determination ... About the necessity of single coders, you always need a single coder to get projects started ... but this isnt rocket science for God's sake. The Linux kernel IS a lot more complex and fragile than a friggin 2D multiplayer game engine, and it seems to manage just fine with its development model.
Mr Ekted Posted August 26, 2003 Report Posted August 26, 2003 This is -*BAD WORD*-ed up. This development board is dead. Nothing to develope. Priit seems to be the only person in the world who knows something about security and 2D rendering, at least that's what it seems if we have to attend Mr Ekted opinion. I'm afraid to say Mr Ekted doesn't know the game very well in all those technical internal aspects we were talking in here. Discovering how bad is the greening system at 2003 is not a good thing for someone who is leading the game. Saying that 8 encr systems with 32 bit keys are hard to crack as 1 encr system of 8x32 bit keys means he doesn't know -*BAD WORD*- about hacking encryptions. He is the authority because he made the menu of Continuum. And Priit did rewrite the game so Trench can keep on running, that's all. If somebody is planning to write a new game similar to SS he should start his own forum and development team and forget about Priit and Ekted, forget about Continuum and SSC. If he does a good job it is only a matter of time to get new zones running or to get old SS/Cont zones moving to the new game. I really don't know how it can be done on the legal side. I don't know if still VIE or JeffP or PriitK owns the rights. It depends on which country we are talking about. I think it is abandoneware in USA, right? I don't think making a team of students will help. Computer projects are hard to coordinate. An international team won't help. It will be like an orchestra with 10 directors and 1 musician. It has to be a sort of personal project like it was to Jeff and Priit, with some extra collaboration, as Mr Ekted did. So, there is no use to keep on talking on SS/Cont forums. Good luck everybody. First of all, I didn't look into green code because I didn't care about it. It's not like it took me 4 years to figure out. It actually only took me a couple of days. You misquoted me about encryption schemes...and you are wrong. I said that a 32-bit key plus 8 encryption algorithms is the same as a 35-bit key. Who says a single encryption algorithm has to be a single function? You can use the key in any way you want. Maybe each set of 4 bits in a 32-bit key selects one of 16 different algorithms. It doesn't matter. 32-bit key with a 3 bit algorithm selector allows for 2^35 results. Blah blah blah. I do not claim to be the authority on anything, least of all for my part in Continuum. My Subspace experience comes from writing Powerbot, ssVCR, and a few other internal tools. I did what I did without !@#$%^&*istance from anyone. I kept it to myself so as to protect Subspace from cheating for as long as possible. I did not use what I knew to attack servers, or share my knowledge with others who would. You are correct CoCo; It is a waste of your time to participate in this forum. You seem to think that every idea is getting overnight delivered to Priit's inbox, and that he's just sitting there waiting for stuff to do. Since you are the local authority on Subspace, online games, and security (at least according to that guy...what's his name?...oh yeah...Coconut Emulator) you should have no problem releasing your own Subspace replacement by, say, Sunday? I'm looking forward to playing it.
madhaha Posted August 26, 2003 Author Report Posted August 26, 2003 Can someone clarify exactly which parts of the code can be open source and which parts must be closed source so we can at least produce a specification.
Mr Ekted Posted August 26, 2003 Report Posted August 26, 2003 Parts of what code? I would say ALL CODE must be closed-source to make the most secure client. Think of it like this. You design a building with a small section of it very high security. You publish detailed blueprints of the entire building except that one area. Now the location of the secure area can be seen, as well as accesses to and from it. It is that much easier to make an attack plan. Also, let's say you open-source everything except the encryption. People can still take all the open-source files, change ship movement, damage, weapons, walls, etc and cheat. Exactly what parts of a client can you allow someone to modify and recompile without sacrificing security? Not the map, not the physcis, not the network/encrpytion. And how do you distribute the secure part? Are you proposing to make a group of people to make a new client? Let's say you had a new client today. Would any zone start using it? If they did, how long do you think they would stay on the SSC biller? If they lost biller access, then they would isolate themselves from the rest of Subspace. So any real development effort really needs to be client/server/biller/directory-server AND THEN you need to find a host. So basically what it comes down to is making a brand new game from scratch.
PinkyAndThaBrain Posted August 26, 2003 Report Posted August 26, 2003 Also, let's say you open-source everything except the encryption. People can still take all the open-source files, change ship movement, damage, weapons, walls, etc and cheat. Exactly what parts of a client can you allow someone to modify and recompile without sacrificing security?None for clients which can play on the official servers. how do you distribute the secure part? Not ... it is not needed for development of non-secure parts of the client. You can connect to your own server without encryption. Are you proposing to make a group of people to make a new client? Let's say you had a new client today. Would any zone start using it?If they did the same thing PriitK did they wouldnt need any zone to start using it as such. If they did, how long do you think they would stay on the SSC biller? That is a political issue ... if things go on as they have I dont think it impossible for a new client to be embraced again. Happened before, can happen again.
numpf Posted August 26, 2003 Report Posted August 26, 2003 The dev board isn't dead, given the activity and # of topics. Development of bots and custom billing servers and their features is still important. ASSS is open source and extensible and set to replace subgame, so you can develop for that. And of course issues relating to general clients can be discussed, and frankly it wouldn't be so hard for anyone to rewrite the client. Continuum is another issue. It is effectively a production product, and should NOT be thought of as a pet project for you moronic amateurs. The security issues are such that it should and will be kept tightly controlled and closed. ek covered the rest pretty well. -numpf
Coconut emulator Posted August 26, 2003 Report Posted August 26, 2003 Ekted covered it pretty well, yes. Rewrite "it" all from scratch means everything: client and servers, the 3 of them. The board is not dead, alright. It is useful for other things, ok. It won't n be next sunday, neither the sunday after sunday. It will happen along the next year, I hope... I start the project today, absolutely on my own. Enhanced settings, recorders and such. I will be working on all that. Suggestions are welcome to squadbot@yahoo.co.uk See you later.
madhaha Posted August 26, 2003 Author Report Posted August 26, 2003 I know I'm going to sound amazingly dense to people like numpf but I need to ask can't ANY piece of the client, even non-game bits, be open sourced? Can the frontend GUI that Mr. Ekted works on be open without exploits? I have a horrible feeling there is going to be a big ugly NO coming my way but there is no way in -*BAD WORD*- anyone is going to code the thing themselves. Its just such a shame seeing so many people that can code pieces of a client but there just isn't a method to pull it together.
PinkyAndThaBrain Posted August 26, 2003 Report Posted August 26, 2003 For someone who would refuse to accept patches anyway open source makes little sense, such as Mr Ekted. In general for hypothetical alternative projects you could open source all the non secure parts and distribute them with a dummy security library which would only let you play on your own server (or servers which put you in their VIP list). This would be the closest equivalent of how ASSS opens the server source. While ASSS can get away with merely close sourcing the security code because the server is not under player control anyway, since the client is the final linking with the security code into a usable client (for official servers) would always have to be done by a central authority.
numpf Posted August 26, 2003 Report Posted August 26, 2003 theoretically almost every part of the client count be opensourced. A necessary exception would be the encryption. However, you couldn't allow anyone to compile the code and play; people would only be able to play if they used the actual compiled binary that you thoroghly protected. The problem with opensourcing parts is that you lose some measure of security. With OS'd code, I could compile certain routines, then try to dis!@#$%^&*emble the cont exe and try to match the compiled routine with cont. So it's effectively like giving potential hackers a roadmap. The menu GUI is not sensitive, and its binary (the DLL) isn't protected (it is however checksumed by cont, so dont bother editing/replacing it). Continuum might be more secure if the menu was compiled in though, if just for the simple fact of making the EXE a larger m!@#$%^&* of code to work through. There's no absolute rule, but since the source code is knowledge, and the only security is obscurity (hiding knowledge), you trade away some security for every line of source you let out. -numpf
Mr Ekted Posted August 26, 2003 Report Posted August 26, 2003 Anything *can* be done. But allowing players to modify ANY part of the client allows them to have their code running inside the process space, which creates a less secure client. The security aspects of the client are not just encryption. They also protect against examination/modification of sensitive data. The protection schemes used sort of wrap the entire client in various ways. Giving out source code plus a security library means undoing almost ALL of Cont's protection.
Smong Posted August 26, 2003 Report Posted August 26, 2003 players to modify ANY part of the client allows them to have their code running inside the process spaceSo is it possible to write an ASSS plugin that extracts the encryption from the contenc module or something?What is preventing people from writing a client that uses the contenc module anyway?
Mr Ekted Posted August 26, 2003 Report Posted August 26, 2003 The encryption algorithm does not exist insdie the server code, only inside the client.
»SOS Posted August 26, 2003 Report Posted August 26, 2003 The server does have the encryption, it just lacks the keystream generator.ASSS at least. I guess PriitK might do some krazi magik in subgame, but ASSS definitely has the encryption.But the keystream generator is the real action part of Continuum's encryption, so there's not much useful to get from just ripping the encryption.
Mr Ekted Posted August 26, 2003 Report Posted August 26, 2003 That's what I said...the algorithm. Making the keystream is the only important thing.
PinkyAndThaBrain Posted August 27, 2003 Report Posted August 27, 2003 Anything *can* be done. But allowing players to modify ANY part of the client allows them to have their code running inside the process space, which creates a less secure client. The security aspects of the client are not just encryption. They also protect against examination/modification of sensitive data. The protection schemes used sort of wrap the entire client in various ways. Giving out source code plus a security library means undoing almost ALL of Cont's protection. 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.)
Coconut emulator 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.
Dr Brain Posted August 27, 2003 Report Posted August 27, 2003 Anything *can* be done. But allowing players to modify ANY part of the client allows them to have their code running inside the process space, which creates a less secure client. The security aspects of the client are not just encryption. They also protect against examination/modification of sensitive data. The protection schemes used sort of wrap the entire client in various ways. Giving out source code plus a security library means undoing almost ALL of Cont's protection. 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.) That kind of release brings two hazards with it. The first and most obvious is that someone can make a client with perfect physics (which has been the major problem with hacked clients). The second problem is that someone now knows what most of the code does, and can find the continuum encryption code easier in the binary. This is a problem to some degree no matter how much code you release. This is why it would be a bad idea to release the menu code. EDIT: Which is almost exactly what ekted said.
Recommended Posts