How suitable is the variant of protecting python code that I proposed?

Question

Python

Good day!
I will describe the situation: there is a simple python project (which, in fact, without taking into account the connected modules, is one .py file). The end user receives it in the form of an .exe built through the same auto-py-to-exe or py2exe (I don’t know which one I will use exactly, so far this question has not been asked). In response to my question "Will the end user be able to parse this .exe and get the source code?" Google replied: "Yes, of course, he does not even have to put in much effort."
So, I set myself the task: to protect the project from getting the source code by the user, who will not go further than stuffing this .exe somewhere.
I want to make a reservation right away: I do not pursue the goal of building a truly stable defense. I just want to make it difficult for the user to get the sources, so that his goal does not justify the money and time spent.
Having gone with my question to Google, I dug up the following options:

• Obsuffing code (like pyarmor)
  
• Translation to bytecode
  
• Downloading the encoded code from the server, decoding it and using it
  
• cython (not an option, because the main bundle of code is the use of imported modules)
  

Ultimately, the idea was born to use a combination of these ideas:
1) Use the download of encoded code from the server.
2) Obsufficate the code (pyarmor).
3) Convert it to bytecode.
4) Build .exe (auto-py-to-exe, py2exe).
Actually, I have the following questions for you:
1) Does such a scheme make sense? What are the pitfalls? Perhaps you want to change / add something? Once again: it will be enough for me even that getting the source code will become at least somewhat more difficult than I just collect the .exe file from .py.
2) Regarding the loading of the encoded code: how to do it? I know that it is possible to download a .py file (for example via urllib or requests), decode it and use normal import. But I would like to do this without saving the file on the user's computer. That is: we load the contents of the .py file in encoded form from the server, put it in a variable, decode it and import it. And here the question arises: how to import from a variable? Maybe I don't know how to use Google (if that's the case, I apologize in advance).
Thanks in advance for your reply!

Answer 1

If you understood the principles of the Python interpreter, the futility of these ideas would become obvious. In particular, compilation to bytecode is always done, no additional gestures are necessary. Decompilation is elementary. And the compile/decompile cycle will render obfuscation useless. Finally, downloading the encoded code would more or less work if the decryption was done at the interpreter level. That is, you will have to write your own Python for this.

Answer 2

The best option is to execute the code on the server, because of the specifics of the python interpreter, everything you listed does not make sense

Answer 3

I will also try to explain.
When developing software protection, you always need to compare the price of hacking and the profit from hacking.
The arithmetic is like this.
If the cost of hacking is k times less than the total profit from hacking (taking into account scaling) and does not greatly exceed the price of rewriting the application, then the product will be hacked and this is a matter of time.
This is a Poisson process, and the larger k is, the faster the likely hack will happen.
The developer, protecting the product, rakes in significant hemorrhoids with support, debugging, diagnostics, updating and expanding the software.
The price of this hemorrhoids may not be much lower than the damage from hacking. Then such protection should not be applied. Especially if your product develops and grows, new features regularly appear in it, and breaking is expensive every time (even taking into account that repeated hacking is cheaper than the first one).
If it is possible to place the code on the server and replace the problem of protecting the algorithm with the problem of authorization verification, then all the hemorrhoids can be taken out into a separate layer of the product, which is sufficiently abstracted from the updated and maintained code.
Loading encrypted sources and bytecode from the server is not practical due to hemorrhoids and the actual rejection of cross-platform, complicating support and diagnosing problems.
A good option is deep obfuscation. You can't get the original sources from the obfuscated code, it's easier to write them again. But you can get a working program.
Obviously, this will not be done by ordinary users, but by professionals and for money. To protect against ordinary unskilled users, it is enough to xbox the bytecode =).
Eventually. With your list of measures, you have a chance to build a bastion around the toilet. If the toilet is with golden toilets, then they will be stolen anyway, and if not, then what for so many hemorrhoids?
If you have algorithmic sections in your code that can be isolated and difficult to repeat or emulate (these should be the necessary functional sections of a really constantly running code), then they can be put into a crypto key in the form of a USB dongle. This is also a considerable hemorrhagic, but sometimes quite applicable.
I don’t know what kind of product you have, it would become clearer if there were details, but in the general case, the following measures work well and are quite effective (if we are not talking about “crowbar”), in descending order of convenience:
1. transferring functionality to the server in the form API
2. bytecode without source codes
3. obfuscation (light)
4. obfuscation (heavy, with support for code polymorphism)
All sorts of packages in executables and encryption are already so ... from the evil one.
Just bring the key resource to the server and that's it.

Answer 4

Ultimately, the idea was born to use a combination of these ideas:

1...
2...
...
5. Stop delusional and understand that there is nothing unique in your code. If two and a half people use it, they will not care how it is protected, and if it suddenly becomes popular, it will be broken anyway. So don't waste your time.