Right, just a couple things. Protecting code was a huge reason I avoided python for years, what's the point when you can just quick run uncompyle6 on your code. It fell mostly on me, with some help, to figure out a way to protect NVG. These are my findings. So first, the python bytecode has nothing to do with cython, so you do not need to modify python when working with cython. It will not add any protection, and will make it so other C extensions will likely fail to load. I can't think of much you'd modify, maybe some function names or something like that, but it's pointless and will result in so much complications it's not even worth it, especially because someone could just copy your modded python DLL and import your module anyway. Scrambling opcodes is a way to protect code, but it can be broken if you are smart about it so I wouldn't. So if you want to use the python compiler and use .pyc files like pyinstaller does by default, by all means download python, scramble your opcodes and rebuild it, it'll work and will stop most people who don't know what they are doing from running uncompyle6, but if 1 person with the right knowledge comes around they will destroy your opcode scrambling protection in about 20 minutes. As far as I've learned, the correct thing to do is indeed use cython. If you cythonize code, it turns it into native C, then compiles it to machine instructions. This means that you can run something like ida on it and get assembly instructions, but because a lot of the gruntwork is handled by python, it will be very difficult to understand. Needless to say you won't have to worry about someone getting assembly instructions, modifying it and releasing there own game. I won't say it's impossible because saying that anything is impossible is just having a closed mindset, I'm sure there is someone out there who could somehow break stuff, and there is certainly hex editing that could be done to the already compiled package or other disassembly/modification methods, but cython is the very best protection I think you can possibly get. But I haven't really answered your question yet have I. You want to know if cython is a secure option because you can import modules compiled with it. The answer is that if you use purely cython? No it's not, anyone can import your module and call it's functions, but will not ever be able to attain runnable python source code from just having the pyd file, at least as far as I know. I mean it's turned into C then compiled into assembly instructions, so the original code doesn't exist in the pyd in any form, just the logic, which because of cython is really really hard to determine from assembly instructions. Basically what I'm saying is that to the best of my knowledge, the technology doesn't currently exist at this time to turn pyd files into runnable code, and likely won't for a very long time and if it does it will probably be using technology beyond what I can imagine lol. So anyway, no cython alone will not stop someone from importing your modules. However, cython + a bit of creativity can lead to the best code protection system you could ever hope to have. Remember, all code in your file being imported executes. This means that with a bit of creativity, you can cause the import to fail spectacularly if something doesn't meet your conditions. For example. Imagine you create a variable called token. By default it's set to 0. In all your important functions, you check to see if the token is equal to 927184. If it's not, you cause some sort of fatle crash that causes the app to stop working. There are many ways to do this, you can import wx, create a wx.app object, then destroy it and call one of it's functions, for example, and it'll cause py to die. I'll let you figure out that on your own. Or if you don't want a crash you can show an error message and exit, or even just make the function return. Don't make a function for token verification, recopy the code for each function so it can't be monkeypatched. Now if someone imports your module and tries to misuse it, they can't because the token isn't set to 927184. So unless they know that number to set it to, they can't do anything but dir and get a list of vars or something. In your game, when you import it, just set that token and your module will work fine. Maybe you can create a variable in the sys module before importing your module. At the top of that module, just have the line sys.varname. If it doesn't exist, it'll traceback and the import will fail. I have other ideas but some of them I'm using so I don't want to tell you them, but the idea is just find a way to be creative. For example you are making a game that is going to be compiled into an executable. You know exactly what you need. You think you'll need the dir function? Probably not. So in your protected modules, just monkeypatch the dir function to your own that returns an empty list. Why not, you won't need it. Then if someone imports your module, they can't use dir to see what's in the modules. Just stuff like that. Cython + creativity is, as far as I know, the best protection you can hope to get for your app in python where most things are about open source. Just remember that there is no perfect system and someone will eventually come around and crack it no matter what you do. But the combanation of cython making it so you can't get the original code + creativity can hopefully outsmart most people. Just think of something clever. I mean at the root that's all encryption really is. When making a secret code, the idea is to come up with something more clever than the person your keeping the secret from. It's the same here. Knowing that there is a remarkably high chance that no one will be able to disassemble your pyd files enough to figure out the logic properly, come up with some clever way to make the import fail if it doesn't meet your conditions. Just don't tell anyone what it is.
I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com