25 Jul, 2009, Lobotomy wrote in the 1st comment:
Votes: 0
I don't suspect that there is any yet, as my Google searches have yet to reveal anything to the contrary, but I'm wondering if anyone here may be aware of a tool for creating Windows executable files out of Python 3.1 code. The only utility I've been able to find information on is py2exe, though it seems that they have not yet updated that program to be usable for the more recent 3.x versions of Python.
26 Jul, 2009, Davion wrote in the 2nd comment:
Can't you just associate all .py files to the python interpreter? Should make it 'executable'.
26 Jul, 2009, Lobotomy wrote in the 3rd comment:
Well, yes, but I'm referring to Windows executable files, though. I.e, the .exe file extension. py2exe, for instance, is a program that'll take a Python script and, instead of merely generating bytecode which can be reverse engineered easily, compile the code into actual native machine code as a single executable file; or something to that extent, anyways. It just doesn't support Python 3.x yet, which is the problem with that particular one.
26 Jul, 2009, David Haley wrote in the 4th comment:
If you're seeking to use py2exe and friends for 'security via obscurity' and are worried about people reverse engineering your code, you might want to look into what exactly it is that py2exe is doing for you. In particular it is most certainly not "compiling" your Python code into completely native machine code, at least not in the way you seem to think.
26 Jul, 2009, Lobotomy wrote in the 5th comment:
I see.
28 Jul, 2009, Lobotomy wrote in the 6th comment:
As a update to this thread, I just came across a promising-sounding tool called cx_Freeze. I've not tried it out yet, although I will be shortly (or in the near-future, anyways). As an aside, I'm curious: Has anyone else used this particular tool before?
28 Jul, 2009, Runter wrote in the 7th comment:
Lobotomy said:
As a update to this thread, I just came across a promising-sounding tool called cx_Freeze. I've not tried it out yet, although I will be shortly (or in the near-future, anyways). As an aside, I'm curious: Has anyone else used this particular tool before?
I think it's main selling point is the cross platform functionality. It probably still suffers from the same security via obscurity mentioned earlier. This types of things are notoriously easy to 'decompile' by anyone you would have been worried about reading the code in the first place.
28 Jul, 2009, David Haley wrote in the 8th comment:
What these projects usually do is store code to load up an interpreter, and then store your bytecode literally in some form or another, and run the interpreter on the bytecode. If you look at py2exe, for example, it ships your program with a Python interpreter DLL. If you think about it, really, getting rid of the Python interpreter would essentially mean predicting the entire program's behavior at runtime so that you could compile away the many runtime lookups. Basically these things should be thought of as a convenience for people to run the programs – it makes it all "point-and-click-run" – and not at all as a means to make the bytecode secure.
28 Jul, 2009, quixadhal wrote in the 9th comment:
It should also be noted that MOST things of this nature can be reverse engineered by anyone who's familiar with the bytecode interpreter itself. If you want security, you're either going to have to pay some cash, or do it yourself in some manner.
If all you want to do is make an executable that people can click, py2exe probably works just fine… You could write it yourself if you know the windows API… I'm sure all they're doing is embedding a python interpreter in a tiny C++ framework that loads your script and says "go".
The other question is why you need the security. If it's to keep people from seeing how it works (avoiding exploits, etc), that's only feasable if it's a client/server system – and then you keep most of the logic on the server side. A self-contained system can ALWAYS be broken down into assembly code (or bytecode in this case), and then analyzed. Remember, teenage hackers have more energy AND more free time than you do, so you will never beat them. *grin*
If it's to keep people from using your product (or copying it), you have to ask yourself if you want to take the high road and try to make it so useful that people will buy it for the tech support, or just because it's cool…. or the low road of writing obscure code that jumps through hoops that serve no purpose other than to obfuscate people trying to pick it apart. I call it the low road, because that's the direction that leads you to copy protection schemes, like requiring an internet connection and sending MD5 checksums of the code back home for comparison (and disabling it if they don't match), or breaking things into modules which are all block-encrypted, or other such ideas.
In many cases, it comes down to scale. Lots of game publishers pay huge sums of cash to license protection systems that abuse all kinds of specs to try and make it harder to duplicate their CD's, DVD's, etc. In many cases, these systems end up costing them in terms of bad PR, extra tech support that has to field phone calls for folks who can't run X on hardware Y, or in some cases angry because the protection damaged their hardware. Yet some of the biggest sellers don't have protection at all… look at Turbo Tax. Every year they sell millions of copies. I'm sure millions more get pirated, yet they seem to be doing quite well.
If all you want to do is make an executable that people can click, py2exe probably works just fine… You could write it yourself if you know the windows API… I'm sure all they're doing is embedding a python interpreter in a tiny C++ framework that loads your script and says "go".
The other question is why you need the security. If it's to keep people from seeing how it works (avoiding exploits, etc), that's only feasable if it's a client/server system – and then you keep most of the logic on the server side. A self-contained system can ALWAYS be broken down into assembly code (or bytecode in this case), and then analyzed. Remember, teenage hackers have more energy AND more free time than you do, so you will never beat them. *grin*
If it's to keep people from using your product (or copying it), you have to ask yourself if you want to take the high road and try to make it so useful that people will buy it for the tech support, or just because it's cool…. or the low road of writing obscure code that jumps through hoops that serve no purpose other than to obfuscate people trying to pick it apart. I call it the low road, because that's the direction that leads you to copy protection schemes, like requiring an internet connection and sending MD5 checksums of the code back home for comparison (and disabling it if they don't match), or breaking things into modules which are all block-encrypted, or other such ideas.
In many cases, it comes down to scale. Lots of game publishers pay huge sums of cash to license protection systems that abuse all kinds of specs to try and make it harder to duplicate their CD's, DVD's, etc. In many cases, these systems end up costing them in terms of bad PR, extra tech support that has to field phone calls for folks who can't run X on hardware Y, or in some cases angry because the protection damaged their hardware. Yet some of the biggest sellers don't have protection at all… look at Turbo Tax. Every year they sell millions of copies. I'm sure millions more get pirated, yet they seem to be doing quite well.
29 Jul, 2009, Runter wrote in the 10th comment:
Or follow the Software as a Service business model. Also I don't think it's a low-road when it's any other purpose than 'making it so useful that people will buy it for tech support.' I just wonder how viable your so-called low road is. Putting aside the part about obfuscation.
Random Picks
