要知道，獨立的可執行檔案決不會讓應用程式碼變得安全，從這樣的可執行檔案中反編譯嵌入程式碼雖然不易，但確是可行的。更重要的是，這種反編譯的結果（如果使用適當的工具）可能與原始原始碼非常相似。
基於這一事實，對於洩露應用程式碼會對組織帶來危害的閉源專案來說，獨立的 Python 可執行檔案並不是一個可行的解決方案。因此，如果僅複製應用的原始碼就可以複製你的整個業務，那麼你應該考慮使用其他方法來分發應用，比如，僅提供軟體作為服務可能是更好的選擇。
使反編譯更難
目前，並沒有可靠的方法能夠保護應用不被可用的工具反編譯，但是仍有一些方法可以使這個過程變得更加困難。
更加困難並不意味著被反編譯的可能性更小，對於某些人來說，最吸引人的挑戰正是最難的那些，並且挑戰的最終獎勵是非常大的，就是你設法保護的程式碼。
通常來說，反編譯過程包括以下幾個步驟：
-
從獨立可執行檔案中提取專案位元組碼的二進位制表示；
-
將二進位制表示對映到特定 Python 版本的位元組碼。
-
將位元組碼轉換成 AST。
-
從 AST 直接重新建立原始碼。
雖然無法阻止開發者對獨立可執行檔案進行這種逆向工程，但是這裡給出一些想法，可以阻止反編譯過程或者使其結果變得沒有價值，比如：
-
執行時刪除所有可用的程式碼後設資料（文件字串），從而稍微降低最終結果的可讀性；
-
修改 CPython 直譯器使用的位元組碼，這樣從二進位制轉換成位元組碼、隨後再轉換成 AST 需要花費更多精力；
-
用複雜的方式修改 CPython 原始碼版本，這樣即使得到了應用的反編譯原始碼，沒有對修改過的 CPython 庫反編譯也是沒有用的；
-
在將原始碼打包成可執行檔案之前，對原始碼使用混淆指令碼，這將會使反編譯後的原始碼變得沒有價值。
需要注意的是，這些解決方案都會使開發過程變得更加困難，其中的某些想法要求開發者對 Python 執行有非常深入的理解，而且每一個想法都有許多陷阱和缺點。
大多數情況下，這些方案只是將反編譯的過程推遲了而已，一旦你的把戲被識破，所有額外的努力都將變成時間和資源的浪費。
要想不讓閉原始碼洩露到應用之外，唯一可靠的方法是就是不以任何形式將其直接傳送給使用者，只有你的組織其他方面的安全性都做得很好時，這種方法才有效。