Coconut emulator

Making it server-authoritative so you can only play it in LANs? I haven't seen such a stupid program, no.

About "secure movement"... we agreed on another topic in this forum that secure movement (server driven) is silly and will make the game unplayable.

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.

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*

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.

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.

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.

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.

Executing code dynamically sent by server?? It is the craziest idea I've heard in a while.

Hrmm why not. We can pay to Priit the same we could pay for the game on stores... But a lot of players are under 18 years old... not much money for games and things... most of them won't pay a cent... Why don't you open another poll topic to answer that to everybody? heh

LOL!!! madhaha!!!! ARE YOU PRIIT?????? MUAHAHAHA

Nah... just want to say that Smonq is absolutely right... The actual client needs to be modified too to handle the greens in the way we want.

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.

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.

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. 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. 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?

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

He don't owe us anything. But we can't say he did not use the SS code at all. He ripped SS code. There is no difference between source and exe, talking about rights.

Change the green policy can't be VERY hard. I think it can be done without releasing a new Cont verison. Of course a new version of the server is required. This is my first analysis: The client is using a zone setting coming from server to set the max number of greens allowed in the arena. OK. Lets modify the server so it will send a fake setting for that matter (PrizeMaxExist=0) to the client. Having 0 as the PrizeMax setting the client will stop managing randomly positioned greens (this is the thesis I have to prove). Then, the server must take care of all green settings so he can send the random-greens to clients as he was already doing with killing-greens, each green must be sent to all clients with his specific expiration time (when you enter the arena you will receive the list of all existing greens. Each green has a diff expiration time, depending on the moment each one was created and also on the kind of green (random or killing)). I'm going to do a test to check if continuum.exe will resist a PrizeMaxExist=0 without messing it all. It think it is easy to patch that data on the run, just tweaking the zone settings when received from server (running a zone at home). I will try to write a brief explaining how it all can be done, if possible. I know that brief is going nowhere, it is just intended to demonstrate that it can be done without releasing a new version of the client. If you are interested in tracking new "hidden" features you can ask it to me, I would love to help in any way. I can spend some time searching for specific features. We don't have the source code BUT we have the exe code loaded in memory as a readable open book. Coconut emulator

Hehe, Ekted. I did that comparision a long time ago... when I found the random generator was being called for positioning greens on map. It astounded me... hehe it was a cool ICE breakpoint on that routine. Then I went to a zone for a fast check, started 2 clients (which can be done with SS v1.35 as you know) and started shivering when seeing different greens on each map The greens are positioned by the client using a pseudo-random number generator which can be initialized with a seed sent by server. That generator is used to get random coordinates for greens and some more things, *sigh*, so the server can't keep all random generators of clients in synch. The greens placed at "death-points" are sent by server to all clients, and also we all know that they have a different expiration time, we can say, in terms of programming, that they are a different kind of items than the other greens. I don't know all the undies of Continuum, but I don't think it is so hard to make the server to take care of ALL greens like he is actually doing with doors, flags, balls, etc. Not unless the source code is very sloppy and messed, and I don't think Priit is that bad at programming... I think he is pretty good at it. When he will have the time to just even consider it...? who knows...

I'm one the last persons coming to this forum, so I'm not the right one to give explanations, but I think our "mission" is present ideas to Mr Ekted so he can present the valuable ones to Priit Kasesalu. The rest is pure blah blah I think. PoLiX: You are right. The Cont client is not so easy to crack as SS. Priit made a good job, the way I see it. I can't imagine more things that can be done to protect the client from its user. Closed-source is the only way, *but* it doesn't close all doors. I'm a sort of pain in the -*BAD WORD*- to this forum because I always have a "but" for almost everything related to security. Right now, only a few people (I guess) have the patience/time/knowledge to crack the game. But remember sage's times... a single guy messed up the whole game. He didn't need the SS source to write Twister, I supose. It could happen with Continuum too. Write a Twister for Continuum is harder than it was for SS, but still possible. Fortunately, persistent cheaters use to reveal themselves sooner or later... they are lame, heh. Yes... it is harder to prove that the roof is not liking at any point... you have to check the whole roof to !@#$%^&*ure it. And we are talking about an extensive, not really well defined at first sight roof... Define that "roof" is a matter of tracing the whole behaviour of the whole application (server, client, billing) in all possible s¡tuations. Paranoia is the word to define the feeling of a programmer on that matter. What things the user can do to break my software? How can I prevent it? Am I missing something? This awful music never stops in your head. I agree. It is crazy to pretend things like secure movement... you are firing and hiting a ship on your screen but then, the server says you wasn't where you was suposed to be on map and your weapons wasn't hiting him on server because of lag... or the opposite... you wasn't hiting him on your screen and then the server comes to say you killed him... It is no fun playing a game like this. As we all know, if you hit a guy (in the actual state of the game) you can kill him or not depending on lag between you and him, but everyone understand that you have to hit him on your screen or there is no way to kill anybody.Right now, without "secure" positioning, everyone considers his local client time as the absolute time of the game, and it is right. That's why laggers use to say that everybody is lagging but they are not. So, I agree with you: all the things that affect the behaviour of your own ship on screen must remain to be client driven. But I still think that other things like greens could be server driven. There will be lag at the moment of picking the prize because the server must assign it to you instead of your own client. But it has some advantages... like everybody having same greens on their maps (Have you ever wondered why people sometimes does strange movements with their ships trying to reach an empty zone on your map? It could be that he is trying desperately to get a prize placed there ONLY on his screen...). Right now, it is possible for two or more players to pick the same green at almost same time, but it is a minor issue, not related to security but to the logic of the game. Also, and it is the most important thing of it, by controlling the greens the server can control the items of players. It is closing a big door opened to most common cheats (please take away the *prize for smods too!! ). When I talk about greens I talk about any thing placed on map as a tile. The map should be the same for all players, including all kind of temp "tiles" like bricks, greens, flags, doors, soccerballs, etc. There is no problem at the moment with expiration time for bricks, flags and balls, synchronism for doors, etc. But greens are a big hole in the game right now, the way I see it. I'm already calmed, thx bro

I feel as the real evil -*BAD WORD*- I am, Ekted I don't have the right to supose what urge you feel or not. You are in a difficult position... giving the face to players and having to deal with Priit at same time, and doing I don't know how many things more. All what your work deserves is respect, Ekted. From a cracker to a cracker: I suck big time. I do agree with PoLiX. I think we haven't heard a voice defending an open-source client lately. The actual server can be open-source, just because most players won't run the zones they play from their computers and there's almost nothing to hack on server as you say. Having the source of the client makes easier to cheat, but it's still possible without it.

OK I admit I was an -*BAD WORD*-. I thought Ekted was insulting me. English is not my native lang as you said, etrigan. I admit obscurity is the only way, but I also say that it is not enough. Peace out.

OK, here I stop agreeing. And I want to be mean too. A couple of things.... You think my ideas are not serious, they are the typical technological rhetoric... OK. First: I'm not talking about rewrite the whole protocol to be server authoritative. I'm talking about redoing parts of it which will always be a problem in its actual state. I can discuss it in detail if you want. PGP encryption and open-source ideas sucks, I still agree on that. Second: I haven't heard any argument, good or bad, besides the tipical "oh no no no, this just can't be done" thing. I would like to hear a good reason which makes SO impossible to let the server take care of a few things that are client side at the moment. No wonder that you've been guessing for years how to enhance game security. I don't see any significative advance on that. You are just lucky because there seems to be no people like sage386 around the game at the moment. But your "work" on the SS/Cont protocol deservers a plague of sage386s flying around. Talking about Continuum protocol as a better thing than the SS protocol is just an illusion. I say closed source is the best way it can be done. I say obscurity is your only weapon (a poor weapon, but it is almost the only one). And yes, I wrote some more than a single line of code. One of the last personal projects I've been working on is a 3D engine based on DirectX (COM objects fully written in !@#$%^&*embly) which can be called from a lot of languages like C++ and Delphi. The core is finished at the time and it is fast as -*BAD WORD*- and also very customizable. I have built some pretty demos with it. That's why I arrived here to discuss the SS protocol. I'm planning a 3D multiplayer game with it and some more things. I'm not going to start the multiplayer game until I design a better protocol than the SS/Cont one. I know well some security issues can't be solved that's why I'm not currently developing my own internet game. I feel like spending some more time analyzing SS protocol, to learn how things must not be done. And it's not so easy to come here and say things like I said. Come here is easy, yeah, but the things I said aren't easy. It took me months to crack this -*BAD WORD*-. I know very well what I'm talking about. If you think I'm fake and bluff you're plain wrong. So John Carmack says that closed-source obscurity is the ONLY solution to "good enough" security in fast-action games... I admit it is the ONLY solution but I seriously doubt it is good enough. -*BAD WORD*- John Carmack is all I can say. Also (and now I'm really mean), from a cracker to a cracker, I seriously doubt you cracked the whole game (a lot of more than encryptions and protocols) in 2 months and didn't feel the urge to rewrite parts of it that remains the same by now, Ekted. I see you guys will be trapped here for years... good luck with it. The client just can't be protected from its user. Period. Have a nice journey. Coco

What it took me two months to crack, two years ago, it takes 1 week to me now. I try to be in the skilled/persistent side, not in the malicious one. But, anyhow, I have to agree again. Boredom, frustration, paranoia, are the best weapons against crackers/hackers/whatevers. I agree to what nintendo64 said too.

Yes... I'm talking about other game... I understand that my proposals are about rewriting the whole game, in a way that will be nearly impossible to write a game server to accept the actual client and "my" client at same time... So I'm talking of other game I guess. And yes, I have to agree, Jeffp's/PriitK's solutions are valid and necessary. The game is getting better, in the technical side I mean. We all hope Priit will hear you "one of these days" asking for enhanced zone settings and such. That kind of discussion is much more valuable than talking about rewriting the whole thing. But, oh -*BAD WORD*- it comes the "but", I think that passing the green control from client to server won't surprise anyone. Does people usually complain about how laggy is to get the soccerball sometimes? That's because the server must assign the ball to you and tell it to everyone so all can see ball carriers on their maps (if the corresponding setting is on). By controlling the greens at server side, the most general kind of cheaters (but not all, sigh, I know) will be stopped. Fortunately, twister times passed by. It doesen't seems to be any cheating progs around... huh? Well... there always will be someone screwing here and there, but all of we know how sad Twister times were... tones of people jumping, bricking, thoring like mads. Oh well, there's a few I can do or say to help the game in its actual state. I don't mean to harm it in any way too so I better shut up. Another "last" thing: I'm not pretending to teach you how the game is, Ekted, neither to anyone else, I'm just trying for most people to understand what are we talking about... So true. But oh well, this topic is about gravity bombs... vote yes!! vote yesssssssss!!!!!!! Coconut emulator