Why "encrypt your Python source" isn't always protection
A look at the most common way people try to protect commercial Python code, why it comes apart, and what actually changes the math for an attacker. You wrote a Python desktop app. People pay for it. You would like them to keep paying for it, rather than passing around a copy with the license check commented out. So you look for a way to protect it, and you find a familiar suggestion: encrypt your source. The pitch is clean. A tool takes your .py files, encrypts them with AES-256 into some new extension (often .pye ), and installs an import hook. At runtime, the hook decrypts each module back to Python and hands it to the interpreter. Your source is "encrypted at rest", the marketing says, and there is no performance hit once a module is loaded. It sounds strong. AES-256 is strong. But the strength of the cipher is not the question. The question is the one every protection scheme has to answer: where does the key live, and what do you get when you decrypt? The two que...