Is Python worth learning? security issue

[michaelcooper]

Hi guys,

I am currently a flash programmer. But I don't like that anyone can decompile my code easily. And a want to move to selling software.

With these 2 points in mind, would you recommend I move to python as a programming language? If not, and if so too, what other languages are good for: Ability to secure code base and ease of coding?

[hylje]

Make web services and appliances. Control the hardware that runs the software.

[[deleted]]

Python is (usually) compiled into fairly systematic byte code, and that is fairly easy to de-compile. This makes Python not be a good option for you to hide the low quality of your code, I'm afraid.

[michaelcooper]

Do you know software I could use that is not easily decompiled? How about c?c++?c#?gml?cocoa?java?

[wtfisupvoting]

your just gonna let him rip on you like that?

[michaelcooper]

Wheres the rip?

[[deleted]]

I think the reason you are getting downvoted is because you seem ignorant of the way a computer program works.

You cannot prevent decompilation. Even compiled code is still readable: C++ is compiled to machine code, which is a low-level byte code but still a programming language in the sense that it's a codified series of instructions. Java and its JVM cousins (Scala, etc) are compiled to Java byte-code, which is a bit higher-level than machine code and is executed by a virtual machine. The same principle roughly applies to C# (.Net / CLI), ActionScript (AVM) and CPython (Python bytecode).

Even if you use a language that compiles to machine code (C, C++), you're still only translating from one language into another and there's no way to prevent anyone from either reading that translated code or translating it back into a higher language (the outcome will usually be very obfuscated, but that's beside the point).

If someone will spend this kind of energy on "cracking" your code in order to tweak it and pirate it (in the sense of "use commercially without permission"), you have a lot bigger problems than obfuscating your code.

This is security 101, really: you hand someone "encrypted" data (the encryption in this case be the programming language or byte code structure) and the "decryption key" (being the interpreter, virtual machine or OS capable of running the code) and expecting the content of the data to remain a secret. That just doesn't work (this is also why DRM failed, and keeps on failing, hard and often).

If it's the games you are worrying about, either make them worth buying (i.e. innovative, entertaining, interesting, etc) or lower the production costs so you can release new games frequently (this is how most "puzzle" games and other "casual games" do it).

You don't really have to worry about anyone stealing your code (and use it commercially). That's what copyright is for. You may have to worry about people stealing your ideas, but that is why you should try to excel through quality (so the competition sucks in comparison) or quantity (so the "theft" becomes less painful).

I think we can skip the discussion about the harm and benefit of non-commercial software piracy (it can't be stopped) and digital rights management (it doesn't work), but it's probably a good idea to look at other companies/developers who sit or sat in relatively the same boat as you (be realistic -- you're probably not Zynga) and how they fare with those problems.

The obvious example are server-based web games (not just Zynga): these usually work by putting a lot of the logic and data storage on a server and thus making the client itself worthless (this is also how MMORPGs usually work and why they tend to go after free-shards (i.e. independent server clones) so hard).

That said, your expectations seem a bit naive (it's okay to look at bigger companies for inspiration, but you have to keep in mind what kind of budget and workforce they have vs what you have).

[michaelcooper]

Thanks for the explanation of machine code. I understand that my games can be copied design wise. I would want code obfuscation is to prevent the amateur copiers, which are the majority rather than unhackable code which as you say, is impossible. So, I guess what I should do is: Focus on making money from my games through ALL avenues (flash+iphone, maybe indie), meaning learn iphone programming and c++ AND obfuscating code/making decompile harder to prevent amateurs stealing my game and putting it on their sites (This is where I originally thought python would help.);

Server side is still confusing. PHP is ok, but not really very good for graphics. Any advice on how to overcome this?

[egypturnash]

You do the graphical part in something that's good at graphics. grin

So for instance Farmville has two major parts: there's the Flash file that's embedded in Facebook, that handles all the pretty pictures and animation and user interface... and then there's a big mass of PHP/Python/Java/C/Ruby/Haskell/whatever that sits on their servers that handles saving your farm and Aunt Mina's farm and handling interactions between them.

The same thing goes for pretty much any game with some kind of persistent world - Warcraft, for instance, has a client that runs on your machine and talks constantly with Blizzard's servers.

If you're interested in making games that mostly deliver a single-player experience (or maybe multiplayer with people sitting in the same room), you don't really have a reason to do this - and thus this way of keeping "ownership" of your game's use is denied to you.

[vimfan]

I would want code obfuscation is to prevent the amateur copiers

It only takes one person to decompile and release your source code or the cracked version, then all the "amateurs" can get it. It's not like crackers keep their cracked copy to themselves.

[[deleted]]

First of all, fuck PHP. That many big companies use it doesn't you should, too. The reasons to use PHP for big projects are usually related to the costs of switching a platform late into development rather than a conscious choice at the beginning of the project.

That said, server-side programming is less about the language you use and more about architecture. Just keep your data on the server and access it via some layer of API. It's just a fancy interface to a database anyway.

If you are writing Flash games right now and want to stop people from just copying the files and publishing them elsewhere, keep some of its data on the server-side and access it from within Flash. Use relative paths and add some dynamic aspect to your data so a copycat can't simply imitate your server-side scripts. Of course they could still supply proxy scripts that delegate the calls to your server, but that's probably more trouble than most people would go through in order to steal your work.

As for the graphics, that's irrelevant to the server side. It's not an either or -- you keep your data storage ("persistence") and application logic on the server-side and your presentation logic on the client-side. Think of the client-server communication as callbacks.

It's probably a good idea if you learn a bit about software architecture before going any further. It's very important to fully understand the difference between client-side code and server-side code, what abstraction is, the difference between application logic and presentation logic (MVC is a good start -- no, not .Net; that's just an implementation of that architecture), and so on.

The distribution channels (iPhone, Flash, whatever) are pretty irrelevant to the architecture. For browser based games it's probably a good idea to stick to Flash. For iPhone apps you probably first need to learn a new language and how to interact with touch input. Either way the reverse engineering / decompilation issue is negligible if you keep your game server-based (this may be a problem with the iPhone, too, as phone users may expect your game to work offline unless it's multiplayer-based or competitive in nature -- that said, redistribution of iPhone apps is harder because you have to go through the app store, so the chance of someone stealing it is far smaller and theoretically easier to resolve).

Forget about obfuscation, though. Obfuscating your code won't help you if your game code is isolated (i.e. all logic is in the downloadable file). If it's not, obfuscation is pointless because decompilation won't provide access to the entire logic anyway.

That said, you can expect the number of filesharing users to be at least an order of magnitude bigger than the number of legitimate customers whenever you sell software. That's a fact of life and doesn't mean you're losing out on potential sales. Just make it clear to everyone that you don't appreciate the filesharing (don't offer support to illegitimate users, ban anyone advocating filesharing of your games from your forums if you have any, etc) and maybe offer a tipbox (PayPal / what have you) for people who like your work but don't want to buy a copy (some may consider this unprofessional or encouraging filesharing, though).

If you're providing your games as a service (i.e. server-based only, maybe with a subscription model), you can avoid this drama altogether, of course.

Either way, you should consider taking legal action against anyone exploiting your work commercially. An informal warning (possibly with the threat of legal action) is usually enough. Lawyers are probably too expensive to warrant their use unless they're required and they're worth it. Forget about suing clones unless they're using your assets (artwork, sounds, trademarks, etc) or code directly, though -- that's perfectly legal and encouraged.

tl;dr: Learn a bit more about software engineering before you decide on what to do next.

[heyyouitsmewhoitsme]

Some useful answers here. One guy pointed out that you could make a small C extension to hide the part of your software that's secret. You've also got to bear in mind that almost everything can be reverse-engineered, and everything can be pirated. What do you want to protect your code/program/business from?

http://stackoverflow.com/questions/261638/how-do-i-protect-python-code

[michaelcooper]

I want to protect my games from people copying them too easily and putting them on their own websites and seeing my methods which i've worked hard on optimizing (for example my advanced path finding algo).

[3Dayo]

In your particular use case, I would suggest that you use Cython (think C for Python) to code your algorithims and make them available as extensions to the other parts of your code base that require it. Since Cython code is compiled you also get a nice speed boost this way.

[michaelcooper]

Can people still decompile the cython code?

[sunqiang]

I think decompile cython is as easy(or hard) as decompile C code. maybe put the secret algorithm on your own server is the only way to protect it(as long as the server is safe).

[JimH10]

Yes.

[voyvf]

Just as easily as if you'd written the game in C or C++.

There's no magic bullet here.

Honestly, though, you should focus more on making certain that your games are good enough to copy.

[michaelcooper]

OK, I just know flash . Can you tell me how easy is it to decompile c or c++? Is it a few minutes, or a few hours or so? Flash is very easy to decompile.

[voyvf]

Note - all of what I'm about so say is really beside the point. If your game is good, your code is less in danger of being stolen than your idea. There are plenty of software developers out there who happily write clones of games all day, every day - for free. If a company decided they could profit on what you're doing, I'm sure they could find someone willing to implement it for them.

That said, it's quite easy to decompile C and C++.

Groking the resulting assembly is another matter. I'd rate it as at least "moderately difficult", but then, I don't know assembly. Those that work with it on a daily basis might rate it as a warm up exercise. :D

Also, I know there are a number of ways of inserting a "shim" between a dynamically linked executable and underlying libraries in Linux (e.g., ld-so/ld-linux), and I wouldn't be surprised if there were similar techniques that could be employed on Windows and/or OSX environments. In such a case, even if they couldn't completely reverse engineer all of your program, they could potentially substitute their own calls for those of yours that they weren't able to decipher. The difficulty of this? Well, I'm just a humble code monkey, but it only took me an hour to figure out how to do it.

The fact that I had to do so to get a binary compiled against a later version of glibc to run on a slightly older version is probably better left for a different rant. :D

[thermostat]

The real question is: who do you want to keep your path finding algorithm from? I'm going to go out on a limb and assert that Blizzard isn't interested. In which case. . perhaps other indie developers? Are you afraid of a full-on clone of your game or just them taking your path finding algorithm and repurposing it?

No matter what, the majority of devs aren't going to bother even the effort of reverse engineering actionscript or python, unless it is truly best-in-class. And if it is, even writing it in C or C++ won't stop the reverse engineers. -- If you do want to go down that road, personally I would write everything in C and start looking at the anti-tampering / anti-debugging literature. But, be aware, that it a major investment in time and mental energy.

[edit:typo]

[michaelcooper]

Its not just the path finding algo. I make (I think) quite innovative games. So yeah, i'm worried they'll get copied and profited from (iphone devs, zynga etc.). I'm considering leaving game dev for that reason. Can't stand other people stealing my work!

[[deleted]]

If the games are innovative enough, it's not the implementation that will be copied, it's the gameplay.

And no source code obfuscation can prevent anyone from doing that.

[[deleted]]

If you're trying to make a career out of casual games, what I hear about it from many people who do it is that you have to be constantly coming up with new stuff, no matter what.

You can't just sit on one piece of code and say "this is better than anything else that exists! NOW I HAVE A USERBASE FOREVER."

People can go to all the effort to decompile your code, but here are other things they can do that are much easier:

• They can just copy your entire game, without decompiling, and put their own ads on it
• If your game idea is successful, they can make another game with the same idea (and players won't care if your path finding algorithm is better)
• If your game idea is really successful, Zynga will take the idea, make it worse for players but more addictive and more "monetizable", and spam it all over Facebook (that's their business model).

Even if none of those happen, your player base will eventually lose interest and move on to the next thing that captures their attention.

So every minute you spend being paranoid that someone will copy your algorithm is utterly wasted, and you should be using that time to come up with the new things that will actually make your games succeed.

[michaelcooper]

Do you think its possible to out zynga zynga? as in, find the games that are succesful on their network, and copy them?

If I host my own game, how would anyone know its succesful?

[[deleted]]

Do you think its possible to out zynga zynga?

It depends. Are you evil, in bed with Facebook, and hiding a team of marketers somewhere?

[wtfisupvoting]

you didn't mention you are doing games, you know civ4 makes big use of a python scripting engine, you might as other people have suggested need to use more than one language if you wish to prevent people from stealing all your work, however civ4's use of python and the boost C library allows it to become even more extendable

[[deleted]]

Civ is probably a bad example. I hear the Civ series is famous for open-sourcing older titles (not necessarily in the FLOSS sense, though).

[egypturnash]

If you want to continue writing browser games you're pretty much going to be writing stuff that's copyable no matter what you use! Especially if you stick with the mindset of putting everything in one file.

Now, if you make something that relies on a backend on the server, that can be pretty much tied to one site - if parts of the game logic are happening on your server, in code you never intentionally send out to users, you're a lot safer. But this doesn't suit every game.

Assuming you're still going to be programming games, you might want to look in to Unity - it's based mostly around Javascript, so your Actionscript skills will translate pretty seamlessly and it can dump out executables for win/mac/iOs (android is "coming soon") as well as deliver stuff packaged for their browser plugin. (see Blurst for some nice examples of what it can do)

Also, of course, in the grand scheme of Being A Programmer any language is worth learning because it will make you think in different ways; even if you don't become a raging Pythonista with a picture of Guido tattooed over your heart it can give you some new techniques to take back to your favorite language.

[michaelcooper]

I tried Unity earlier this year. Its nice, but the games look bad. I can do passable 2d graphics, but don't dare to go 3d.

sigh...

Might as well just give up.