Since they gonna make it open source and they wanna profit from it then anybody could compile the sources remove some online checks and send it to their friend...If they would be as big as Minecraft they probably wouldnt care. Right now they aint requiring your money to play but soon...they gonna be probably.
Obfustication, why?
- Thread starter jjaquinta
- Start date
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
I\'m not following you. Obfustication doesn\'t stop you recompiling and redistributing. As you pointed out with MCP, you can still do that, it just makes it a bit harder. Any security that relies on client code is doomed anyway. Even the major games are cracked within 24 hours of release.
Commercially, if anyone is copying and distributing to the point of making money, you sue them. But, usually, that\'s rarely necessary. Especially if you have a vibrant and supportive community. And, long term, as Minecraft is finding, the real money is not in selling the client, but in providing a server environment. Servers can be secured. Clients cannot.
Commercially, if anyone is copying and distributing to the point of making money, you sue them. But, usually, that\'s rarely necessary. Especially if you have a vibrant and supportive community. And, long term, as Minecraft is finding, the real money is not in selling the client, but in providing a server environment. Servers can be secured. Clients cannot.
Redistribution aint problem, but I thinkt they are worried about cracking. That\'s only reason I can think of...
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
Sure, you are going to get some people looking at the code for exploits. But you are going to get more people looking at the code and reporting points where it can be exploited. That how the whole public source thing works. Many eyes on the code make for better code!
Basted on this principle, at work, not a single line of my code gets checked in unless at least one other person looks at it. Towards the end of the cycle, that goes up to two. Often even a junior programmer will come back and point out some bone-headed mistake I made in my code. Contrast that with the defects that get returned by the test team: these are in terms of what to do to the UI of the product that makes it break. It\'s far eaiser to fix when someone say \"you have a problem in this line of code\" rather then \"when I pat my head and rub my stomach, it breaks\".
Even assembly language clients can be cracked. If your revenue model relies on uncrackable client code you\'re doomed.
Basted on this principle, at work, not a single line of my code gets checked in unless at least one other person looks at it. Towards the end of the cycle, that goes up to two. Often even a junior programmer will come back and point out some bone-headed mistake I made in my code. Contrast that with the defects that get returned by the test team: these are in terms of what to do to the UI of the product that makes it break. It\'s far eaiser to fix when someone say \"you have a problem in this line of code\" rather then \"when I pat my head and rub my stomach, it breaks\".
Even assembly language clients can be cracked. If your revenue model relies on uncrackable client code you\'re doomed.
I agree that programming is a lot mor eefficient and robust when you have more than one brain looking at the code as it\'s being written.
As a matter of fact, other people will spot flaws you were just working on like neons signs, while you can\'t really get why it\'s wrong just yet. Just like re-reading a text you\'ve just written skims some errors, but often leaves many because you\'ll tend to read things at the same time as \"reading\" it as what you had in mind.. I\'m not really wording that right one bit, but I hope you know what I mean.
But if the starmade devs here are not comfortable with doing that, well.... that\'s their thing, isn\'t it?
As a matter of fact, other people will spot flaws you were just working on like neons signs, while you can\'t really get why it\'s wrong just yet. Just like re-reading a text you\'ve just written skims some errors, but often leaves many because you\'ll tend to read things at the same time as \"reading\" it as what you had in mind.. I\'m not really wording that right one bit, but I hope you know what I mean.
But if the starmade devs here are not comfortable with doing that, well.... that\'s their thing, isn\'t it?
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
I love it. I hacked the department\'s computer in college. Crude. I put a trojan into the password changing program. The admins were pissed when they found out. But after they calmed down they made me an admin. After that, instead of spending my time trying to hack the system, I spent my time securing the system. It was an early lesson for me in the benefits of keeping things open.
The original Syndicate was pretty cool. I think I still have the box somewhere. The floppies are probably unreadable at this stage though. I\'ll have to check out what they\'ve done with it.
The original Syndicate was pretty cool. I think I still have the box somewhere. The floppies are probably unreadable at this stage though.
I\'ll have to check out what they\'ve done with it.
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
But if the starmade devs here are not comfortable with doing that, well.... that\'s their thing, isn\'t it?
Of course. This is a suggestion like any other suggestion in the forum. Perhaps a little more meta since it\'s about how they write then code than the specific code they write. But I\'ve seen users rally behind a suggestion they thought would bring benefit to the game and get enough attention to it to change the dev\'s minds. This is no different.
If you think this is a bad idea, you are free to say so and try to convince any poster of that. If you think it\'s a good idea, why not join in working out how to make it happen?
If the devs have explicitly said they are not comfortable with that, the next step isn\'t \"Oh, well\". It\'s \"what is it about it that makes you uncomfortable, and can we find a way to do it that you are comfortable with\".
Of course. This is a suggestion like any other suggestion in the forum. Perhaps a little more meta since it\'s about how they write then code than the specific code they write. But I\'ve seen users rally behind a suggestion they thought would bring benefit to the game and get enough attention to it to change the dev\'s minds. This is no different.
If you think this is a bad idea, you are free to say so and try to convince any poster of that. If you think it\'s a good idea, why not join in working out how to make it happen?
If the devs have explicitly said they are not comfortable with that, the next step isn\'t \"Oh, well\". It\'s \"what is it about it that makes you uncomfortable, and can we find a way to do it that you are comfortable with\".
I did like the SYndicate, and I did enjoy the reboot, but only because I didn\'t ever compare it to the actual old game. They\'re nothing alike if not more than by somewhat similar universes. And the universe is what I liked diving into, rather than the not-so-astonishing mechanics of the 2012 shooter. It was fun, not extraordinary. But I digress!
I like your story and in fact, that\'s most often how computer security works. It\'s somewhat a race that can\'T ever be won by the security guys, because you can\'t really prevent new methods, as that\'d imply you know about the flaw, which implies.. why the heckdid you not fix it? So yeah, sadly, security can\'t ever win this arms race since it\'s mostly based around \"bad guys\" finding an exploit and using it, then security coming up with a way to prevent that with a new measure. The \"bad guys\" then take this new thing apart and find a way to go through/around that as well. And the cycle never ends.
In fact, to have the best security, I don\'t think it\'s rare for companies to actually have their own bad guys literally trying to break into their own stuff. If anything, most security engineers often started playing for the attacking team.
But..ahem... that\'s uhm.. all.. slightly beside the thread\'s topic.
I like your story and in fact, that\'s most often how computer security works. It\'s somewhat a race that can\'T ever be won by the security guys, because you can\'t really prevent new methods, as that\'d imply you know about the flaw, which implies.. why the heckdid you not fix it? So yeah, sadly, security can\'t ever win this arms race since it\'s mostly based around \"bad guys\" finding an exploit and using it, then security coming up with a way to prevent that with a new measure. The \"bad guys\" then take this new thing apart and find a way to go through/around that as well. And the cycle never ends.
In fact, to have the best security, I don\'t think it\'s rare for companies to actually have their own bad guys literally trying to break into their own stuff. If anything, most security engineers often started playing for the attacking team.
But..ahem... that\'s uhm.. all.. slightly beside the thread\'s topic.
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
Consoles games aren\'t sofwtare, they\'re hardware. Their clients are uncrackable. It\'s only in that field that your business model can revolve around uncrackable clients. Even mobile games are moving towards revenue models revolving around downloadable content/in-app purchases. God knows I\'ve tried making money on free-with-advertising mobile apps. It just doesn\'t work.
I\'m not sure where Comr4de got that quote from. I think a better statement would be that moddable games are more likely to be successful than non-moddable games.
Their clients are uncrackable. It\'s only in that field that your business model can revolve around uncrackable clients. Even mobile games are moving towards revenue models revolving around downloadable content/in-app purchases. God knows I\'ve tried making money on free-with-advertising mobile apps. It just doesn\'t work.I\'m not sure where Comr4de got that quote from. I think a better statement would be that moddable games are more likely to be successful than non-moddable games.
I wouldn\'t say it\'s a bad idea, but I wasn\'t expecting to look at the game\'s code until late alpha or even Beta.
Not that you couldn\'t or shouldn\'t before, I just wasn\'t really expecting it.
I think both sides of the fence hold valid points, so in the end, the final word will have to come from the devs sitting on the fence itself.
If I had to pick, I\'d say \"do it\", since that would please the ones defending your stance, and wouldn\'t affect the other party. So I don\'t really know why it isn\'t or shouldn\'t be done.
The only thing I can think about is that the obfustication is hardcoded in a way that\'d make necessary rewriting it all as \"understandable\" and that this could understandbly be a task that\'d pile onto the existing pile.
I know it\'d personally annoy me when working on a project with a partner and that he\'d rename a class or something that had been done since the begining and used everywhere and that even using wonderful tools such as \"Search & replace\" [Science be praised], some little troubles would linger because of this new thing, hidden deep underneath merry and obscure error messages. And then came the horribly fun hunt for those often tiny and frustatingly simple bugs.
I haven\'t looked at the code like you did, so I really don\'t have any idea if this is even a possibility as to why not do it right now, but that\'s the only one I can really think of.
Not that you couldn\'t or shouldn\'t before, I just wasn\'t really expecting it.
I think both sides of the fence hold valid points, so in the end, the final word will have to come from the devs sitting on the fence itself.
If I had to pick, I\'d say \"do it\", since that would please the ones defending your stance, and wouldn\'t affect the other party. So I don\'t really know why it isn\'t or shouldn\'t be done.
The only thing I can think about is that the obfustication is hardcoded in a way that\'d make necessary rewriting it all as \"understandable\" and that this could understandbly be a task that\'d pile onto the existing pile.
I know it\'d personally annoy me when working on a project with a partner and that he\'d rename a class or something that had been done since the begining and used everywhere and that even using wonderful tools such as \"Search & replace\" [Science be praised], some little troubles would linger because of this new thing, hidden deep underneath merry and obscure error messages. And then came the horribly fun hunt for those often tiny and frustatingly simple bugs.
I haven\'t looked at the code like you did, so I really don\'t have any idea if this is even a possibility as to why not do it right now, but that\'s the only one I can really think of.
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
I don\'t think it is entirely off subject. If the obfustication is there as a security measure, the futility of security has a direct bearing.
The software product I work on for my day-job sells for six to seven figures. But we don\'t even bother trying to secure it. There is nothing to stop one of the users copying it and giving it on the sly to some other company. But if that company runs into problems, or wants customizations, or support... they\'re out of luck. In practice, piracy is zero.
Admittedly, the gaming world is different. People are going to pirate. And people do. There are widely available pirated versions of Minecraft out there. Does it affect their bottom line? Probably not. Does the fact they have obfusticated their code reduce it? Probably not.
And that is my central point. If obfusticating the code doesn\'t provide a tangible benefit, and not obfustincating it would... why obfusticate?
The software product I work on for my day-job sells for six to seven figures. But we don\'t even bother trying to secure it. There is nothing to stop one of the users copying it and giving it on the sly to some other company. But if that company runs into problems, or wants customizations, or support... they\'re out of luck. In practice, piracy is zero.
Admittedly, the gaming world is different. People are going to pirate. And people do. There are widely available pirated versions of Minecraft out there. Does it affect their bottom line? Probably not. Does the fact they have obfusticated their code reduce it? Probably not.
And that is my central point. If obfusticating the code doesn\'t provide a tangible benefit, and not obfustincating it would... why obfusticate?
Love dat discussion...But in end looks like \"most\" modding community is gonna want open source. I\'d really like opinion of what schema thinks about it right now. I wonder if he has seen this thread...
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
Obfustication is generally done as part of building and packaging. Most often it works on the already compiled files, and the programmers are never aware of it.
The most popular Java development environment (Eclipse) has a really cool feature called \"Refactor\" which is like search and replace on steroids. Unless you are using some types of soft data references it lets you rename any class or function and scans and updates only the relevant parts of the code. It has saved me many times from stupid variables names that I used early in the development process.
[Longer explanation if you care...
Compiled languages (such as C or C++) go through two phase. First each files is compiled in to an object file. This contains a text based table of all the references to things outside that file. E.g. variables, methods, classes, etc. In the second phase, all those object files are linked together into one big, happy, executable. At that point these textual references are replaces with the actual code locations as laid down by the linker. Since \"go to byte 1234\" takes less space and executes faster than \"go look up where \'foobar\' ended up, and go there\", it is more efficient.
Interpreted languages, such as Java, stop at the compiled phase. A class file retains the textual references. For an outgoing reference, it has the name of the target class, and the name of the entity in that class. For itself, it keps an index of where in the bytecode each name it defines lives. When the program is run, the linking stuff is done as it runs. It is slower, but more flexible.
[[In fact, most modern versions of Java do a \"just-in-time compile\", which kind of does the linking as it goes. So it ends up being much of a muchness. But my digression digreses.]]
So, to circle back, what an obfusticator does is look at all these tables. For the index in each class, it comes up with either random or serialzed names. So the first class might get renamed A, the second B, etc. The first method in the first class might become A.a1(), the second A.a2(), etc. It then goes and look at all the other class files for references to this class file. When it finds them, it updates the tables in the other classes with the updated names.
So, via this method, all the class, method, and variable names in your code (or a section of it) can get renamed to confusing things without impacting the integrity of the code. So it can be done downstream from development and test.
The nifty refactoring I mentioned? It actually operates according to the same mechanism. It can work out, definitively, who looks at the function/class/variable you want to rename and update those references. Although, in that case, you are making the code easier to read, not harder!]
Jo
The most popular Java development environment (Eclipse) has a really cool feature called \"Refactor\" which is like search and replace on steroids. Unless you are using some types of soft data references it lets you rename any class or function and scans and updates only the relevant parts of the code. It has saved me many times from stupid variables names that I used early in the development process.
[Longer explanation if you care...
Compiled languages (such as C or C++) go through two phase. First each files is compiled in to an object file. This contains a text based table of all the references to things outside that file. E.g. variables, methods, classes, etc. In the second phase, all those object files are linked together into one big, happy, executable. At that point these textual references are replaces with the actual code locations as laid down by the linker. Since \"go to byte 1234\" takes less space and executes faster than \"go look up where \'foobar\' ended up, and go there\", it is more efficient.
Interpreted languages, such as Java, stop at the compiled phase. A class file retains the textual references. For an outgoing reference, it has the name of the target class, and the name of the entity in that class. For itself, it keps an index of where in the bytecode each name it defines lives. When the program is run, the linking stuff is done as it runs. It is slower, but more flexible.
[[In fact, most modern versions of Java do a \"just-in-time compile\", which kind of does the linking as it goes. So it ends up being much of a muchness. But my digression digreses.]]
So, to circle back, what an obfusticator does is look at all these tables. For the index in each class, it comes up with either random or serialzed names. So the first class might get renamed A, the second B, etc. The first method in the first class might become A.a1(), the second A.a2(), etc. It then goes and look at all the other class files for references to this class file. When it finds them, it updates the tables in the other classes with the updated names.
So, via this method, all the class, method, and variable names in your code (or a section of it) can get renamed to confusing things without impacting the integrity of the code. So it can be done downstream from development and test.
The nifty refactoring I mentioned? It actually operates according to the same mechanism. It can work out, definitively, who looks at the function/class/variable you want to rename and update those references. Although, in that case, you are making the code easier to read, not harder!]
Jo
- Joined
- Jun 26, 2013
- Messages
- 2
- Reaction score
- 0
Actually I\'m pretty sure the next step is simply \"Oh well.\"
Consider that the devs have their plate probably VERY full with the actual development of their currently alpha build game, and that trying to hold a public forum on why they have their code obfuscated, etc, is just a massive annoyance and a drain on their already precious resource of time.
Also, I would bet my money (and I am not a betting man) that the reason is, as already stated, because the updates are rolling in so very fast, that inevitably there would be countless complaints about people having messed with it and the updates breaking it (regardless of whether that was the intention of releasing source or not).
tl;dr it\'s probably a pain in their ass, and takes time they don\'t have to deal with, not to mention the idea of releasing the source to an unfinished product is sorta silly/stressful, I would imagine.
Consider that the devs have their plate probably VERY full with the actual development of their currently alpha build game, and that trying to hold a public forum on why they have their code obfuscated, etc, is just a massive annoyance and a drain on their already precious resource of time.
Also, I would bet my money (and I am not a betting man) that the reason is, as already stated, because the updates are rolling in so very fast, that inevitably there would be countless complaints about people having messed with it and the updates breaking it (regardless of whether that was the intention of releasing source or not).
tl;dr it\'s probably a pain in their ass, and takes time they don\'t have to deal with, not to mention the idea of releasing the source to an unfinished product is sorta silly/stressful, I would imagine.
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
Well, if you want to sigh \"oh, well\", that\'s up to you. But instead of proclaiming doom and gloom and overstating how horrible it would be, you could look to ways to do it that gets around the problem you cite.
Firstly, anyone interested in the source knows it is going to keep changing. If they choose to whine, then no one will listen to them. Caveat emptor.
Not everyone wants the source to mod the source. I have no interest in writing mods. I think the minecraft approach for mods is the most arse-backwards and is a direct result of them obfusticating their code. I\'d rather write extensions, or help them build their code to be extendable. It\'s a much better approach.
More immediately, I\'d like to write utilities to read and write ships. Since, for whatever reason, they\'ve chosen a binary file format rather than XML, this is hard to do right now. If I had the source code, I could work out the data format without having to bug them about it. Since they are already encouraging people to exchange ship files in this format, it\'s got to be pretty baked and unlikely to change much. Therefore work there is safe.
They don\'t have to \"hold a public forum\". They could just say \"Oh, yeah. Makes sense. Done.\" Or interested parties on this thread could come up with a proposal to them for making the source available. If the whole thing could be community run, then it isn\'t a burden on them.
I\'ve got the decompiled source, and it\'s not too bad. Most of the source files are pretty small, which is generally a sign of good code. I\'ve found the ship writing code, and am puzzling through it. If anyone wants it, shout out. If anyone has ideas to contribute towards puttiung together a proposal for community brokered access to clear source, post them!
Firstly, anyone interested in the source knows it is going to keep changing. If they choose to whine, then no one will listen to them. Caveat emptor.
Not everyone wants the source to mod the source. I have no interest in writing mods. I think the minecraft approach for mods is the most arse-backwards and is a direct result of them obfusticating their code. I\'d rather write extensions, or help them build their code to be extendable. It\'s a much better approach.
More immediately, I\'d like to write utilities to read and write ships. Since, for whatever reason, they\'ve chosen a binary file format rather than XML, this is hard to do right now. If I had the source code, I could work out the data format without having to bug them about it. Since they are already encouraging people to exchange ship files in this format, it\'s got to be pretty baked and unlikely to change much. Therefore work there is safe.
They don\'t have to \"hold a public forum\". They could just say \"Oh, yeah. Makes sense. Done.\" Or interested parties on this thread could come up with a proposal to them for making the source available. If the whole thing could be community run, then it isn\'t a burden on them.
I\'ve got the decompiled source, and it\'s not too bad. Most of the source files are pretty small, which is generally a sign of good code. I\'ve found the ship writing code, and am puzzling through it. If anyone wants it, shout out. If anyone has ideas to contribute towards puttiung together a proposal for community brokered access to clear source, post them!
I guess we could make Github repository where people contribute with PRs with named fields, methods and stuff...Or if there\'s update people interested help to update the source.
Also I consider XML to be slow. Binary is much faster. I know game that consisted of blocks and was using xml for saving worlds. Before binary saving the file size was ~210MB, later after adding binary saving ~2.1MB and 4x faster loading and saving...(Ofcourse the game was written in C++ though...)
It would be possible to use ant to recompile the .jar I think. (been using it a lot lately)
Also I consider XML to be slow. Binary is much faster. I know game that consisted of blocks and was using xml for saving worlds. Before binary saving the file size was ~210MB, later after adding binary saving ~2.1MB and 4x faster loading and saving...(Ofcourse the game was written in C++ though...)
It would be possible to use ant to recompile the .jar I think. (been using it a lot lately)
- Joined
- Jun 25, 2013
- Messages
- 403
- Reaction score
- 11
Sure if we want to go the unobfustication route, we can start keeping parallel sources. We can write the same sort of thing they wrote for Minecraft. But, honestly, I\'d rather put my time into writing tools and utilities.
I was more thinking, if the devs are worried about proliferation, we create a community like the test community. Not a huge bar to get in, but enough to keep it from just being the general public. We ask the devs to give us, say, a weekly dump of code. This is distributed only within the community. Suggested changes are vettd by the community and, once a week, we pass all the up-voted suggestions back to the devs. If things go well we might also ask for a once a week Q&A session with the devs.
That\'s all very rough. But it\'s an example of the way that we can make something like this stress and pressure free and add value to the product.
I was more thinking, if the devs are worried about proliferation, we create a community like the test community. Not a huge bar to get in, but enough to keep it from just being the general public. We ask the devs to give us, say, a weekly dump of code. This is distributed only within the community. Suggested changes are vettd by the community and, once a week, we pass all the up-voted suggestions back to the devs. If things go well we might also ask for a once a week Q&A session with the devs.
That\'s all very rough. But it\'s an example of the way that we can make something like this stress and pressure free and add value to the product.
Most of their tools are written in F# what is like Python I guess...Though yes I like that idea of yours having small community. Still I don\'t have an idea how to write deobfuscation tools...With your idea where schema (or someone) gives us weekly code I like it like I said. For that\'d we need just actual word from devs and get organized and planned...
Speaking as a developer, Schema should make Starmade as true to his own personal vision as he can and implement any feature suggestions that seem worthwhile as he sees fit.
Having worked on closed and open source then served on both solo and committee projects in the real world, I can say that there are merits to both approaches. However, with a project of this nature it should be kept obfuscated and single-minded with a later API for the modding community to add the features that they see fit.
Charlie_, I personally found your car analogy quite apt and have found that too much time can be lost selecting, dismantling and understanding somebody elses code solution instead of just keeping focused and writing code yourself. Large projects such as Linux and Firefox have systems in place to make the open source approach a huge bonus but, at indie level with such a focused project, it would not work so well.
Finally, any good programmer knows that it is a form of personal expression (excuse the pun) and that is why I would rather play \"Schema\'s Starmade\" than a patchwork quilt.
Kal
Having worked on closed and open source then served on both solo and committee projects in the real world, I can say that there are merits to both approaches. However, with a project of this nature it should be kept obfuscated and single-minded with a later API for the modding community to add the features that they see fit.
Charlie_, I personally found your car analogy quite apt and have found that too much time can be lost selecting, dismantling and understanding somebody elses code solution instead of just keeping focused and writing code yourself. Large projects such as Linux and Firefox have systems in place to make the open source approach a huge bonus but, at indie level with such a focused project, it would not work so well.
Finally, any good programmer knows that it is a form of personal expression (excuse the pun) and that is why I would rather play \"Schema\'s Starmade\" than a patchwork quilt.
Kal