简介这是一份面向Python开发者的代码加密与License授权控制方案尤其适合外包项目交付、商业软件分发等场景。它有效解决了两类痛点一是将Python源码编译为C/C再生成扩展模块避免核心逻辑被直接查看或篡改二是通过主机信息绑定和有效期设置阻止未授权机器随意运行代码。资源共9个文件以6个Python脚本为核心覆盖主机信息采集、License创建与校验、时间校验、加密编译等模块并配有Markdown使用说明和.gitignore等辅助文件压缩包仅15KB整体十分紧凑小巧。这些脚本逻辑完整从获取本机标识、生成授权文件、运行时校验到过期处理均有实现并附测试示例与目录结构说明读者可直接参考或移植到自己的项目中。目前已有1040人学习适合有一定Python基础、希望为商业项目增加源码保护与授权机制的开发者借鉴。1. 交付 Python 项目时绕不开的源码保护和授权问题当你把写好的 Python 工具打包交付给客户或者以安装包形式发给企业内部使用时对方拿到的其实是接近明文的东西。.pyc字节码可以被反编译PyInstaller 打的包用pyinstxtractor十几秒就能还原出 Python 源码即便加了 UPX 壳也只是拖慢节奏。更麻烦的是授权控制客户把程序从一台机器拷到另一台机器或者把系统时间改回去License 就形同虚设。这篇内容要解决的就是两个问题——python代码加密怎么做才不是心理安慰以及 License 控制怎么设计才能拦住绝大多数非专业破解者。全文按“选型 → 编译加固 → License 设计 → 防破解验证”推进每一步都有可直接抄的命令和代码。2. python代码加密的三种落地形态与选型边界2.1 先看对抗层级你是防小白还是防逆向工程师python代码加密不是一个动作而是三种不同强度的方案。最低一级是纯混淆把变量名改成a、b、c删除注释和空行用compile()输出字节码。这类方案对业务零侵入但工具链成熟反混淆只是时间问题。网上搜得到的pyarmor、pyobfuscate都是这一派。中间一级是把热点模块转成 C 扩展。Cython 把 Python 代码翻译成 C再编译成.soLinux或.pydWindows。由于最终产物是机器码反编译回 Python 的难度比字节码高一个量级。代价是构建环境要求高很多第三方包里的动态特性比如eval、exec、猴子补丁在 Cython 下会失败。最高一级是 Nuitka 这类“编译型”方案——它把整个 Python 程序连同运行时编译成机器码。注意 Cython 和 Nuitka 的本质区别Cython 是“把 Python 翻译成 C”Nuitka 是“编译 Python 语义运行时链接 CPython 的解释器库”。Nuitka 对语言特性的兼容性极好几乎能编译任何合法 Python 代码这也是近年商业交付中更受青睐的原因。选型边界最后落在三个问题上目标机器是否能跑编译产物、构建机的依赖能否打全、以及你愿意为安全等级付出多少兼容性成本。纯内网小工具混淆就够对外售卖的商业软件至少做到 C 扩展级别如果程序要长期运行在用户环境、且单机授权价不低Nuitka 是更靠谱的默认起点。2.2 常见做法先按部署形态压缩加密范围我一般在项目里先区分“入口脚本”和“业务模块”。入口脚本因为要承接启动参数往往需要保持可读业务模块则全部批量编译。如果你的程序只有一两个.py文件直接整体交给 Nuitka有几十个文件时把包含核心算法的子包比如core/、lic/单独编译成扩展入口保持轻量即可这样调试定位也快。依赖处理是很多人忽略的一点。编译只是把源码变成二进制import进来的第三方库不会自动进到产物里。Nuitka 在 standalone 模式下会尝试收集 site-packages 里的依赖但动态加载、通过__import__()导入的模块基本都会漏。所以选型之后的第一件事不是写编译命令而是梳理你代码里的所有import形态。2.3 python代码加密方案对比表方案产出物防逆向强度部署要求包体积维护成本纯混淆 pyc.pyc低可反编译必须有 Python 环境小低PyArmor混淆脚本 运行时中抗初阶调试需要 Python 环境小低Cython.so / .pyd较高需对应架构兼容中中Nuitka standalone二进制 依赖库高不需要预装 Python大约 30-80MB中“产物可控”和“运行可控”是两件独立的事。通过上表可以看到Nuitka 在交付体验上更接近商业软件这也是后续章节以它为主线的原因。如果你的交付环境限制较多比如客户机器是无图形界面的精简版系统Cython 这边更轻但 License 控制思路完全通用。3. 用 Nuitka 编译加固 python代码的构建参数与依赖打包3.1 构建环境先装干净的解释器和 Nuitka不要在开发机全局 Python 里直接编译虚拟环境是底线。以下是建环境的标准命令python版本尽量对齐你开发用的版本建议 3.8 及以上。conda create -n py_build python3.10 -y conda activate py_build pip install nuitka ordered-set # ordered-set 是 Nuitka 的依赖 python -m nuitka --version # 确认安装成功Nuitka 对 Python 版本的支持策略是“随时追最新”但 Release 版与 nightly 版差异较大。生产构建建议锁定大版本比如 2.x 系列。如果你用 conda 建的 3.9 新环境第一次编译会触发 Nuitka 下载对应版本的 CPython 源码这一步需要外网访问内网环境可以预先python -m nuitka --module预下载一次或者直接用系统自带 Python 编译。编译成功后不要急着验证功能先跑一遍测试用例。Nuitka 编译后出错往往表现为导入失败、sys.stdout被静默替换等运行时问题这些在编译阶段看不出来。3.2 编译单文件入口的完整命令与参数拆解假设你的项目结构是这样project/ ├── launcher.py # 入口负责解析命令行和启动主程序 ├── core/ │ ├── __init__.py │ ├── algorithms.py # 核心算法 │ └── lic_verify.py # License 校验见第4章 └── config/ └── settings.json # 运行时配置文件执行编译的命令如下python -m nuitka \ --standalone \ --enable-pluginno-qt \ --output-dirbuild_out \ --include-data-dirconfigconfig \ --include-packagecore \ --windows-console-modedisable \ launcher.py参数说明--standalone生成独立可执行文件目录包含必要的 DLL/SO 和 Python 运行时。--enable-pluginno-qt如果你的程序用了 Qt这行会触发 Qt 插件收集用不到的库可以不加。--output-dirbuild_out产物输出目录便于后续打包。--include-data-dirconfigconfig把配置目录直接复制到产物根目录。重要Nuitka 不会自动跟随普通数据文件配置文件、证书、模型文件等必须显式指定否则运行时会因找不到文件而崩。--include-packagecore强制把指定包编译进二进制防止core被当作普通字节码随行。--windows-console-modedisableWindows 下关闭控制台窗口若在 Linux 构建忽略即可。第一次编译会较慢几分钟到十几分钟之后增量编译普遍几十秒。编译完成后在构建目录下找到可执行文件直接在本机跑一次。3.3 依赖收集失败怎么排查先看 .build 目录里的日志依赖缺失是 Nuitka 使用中最常见的失败点典型表现是编译成功但双击 exe 闪退或提示ModuleNotFoundError。先看 Nuitka 生成的中间报告在build_out/launcher.build/目录下有一个文本文件记录所有导入解析结果搜索WARNING字样。grep -ri WARNING build_out/launcher.build/ | head -20关键排查项有三个动态导入代码里出现__import__(module_name)或importlib.import_module()Nuitka 无法静态分析需要手动补--include-module。通过字符串引用的类名getattr(module, ClassName)不会直接导致 import 失败但会让core包里的文件名被忽略。需要逐个验证。C 扩展模块.so或.pyd依赖的底层库如libxml2、libssl没有被复制。在 Linux 上用ldd检查编译产物在 Windows 上用dumpbin /dependents。ldd build_out/launcher | grep not found如果出现libpython3.10.so.1.0缺失在构建机上执行以下命令再重编export LD_LIBRARY_PATH/path/to/your/python/lib:$LD_LIBRARY_PATH很多团队在 Nuitka 之后再加一层 PyInstaller 聚合负责把 Nuitka 的产物目录打包成一个安装文件。这个组合写法不是必须但能显著降低安装步骤在单文件 30MB 以上时还支持手工分发整个目录避免解压缓慢。4. License控制模块非对称签名、机器指纹与离线激活4.1 License控制为什么必须绑定“运行环境”而不是“程序本身”很多人在加密后马上做 License但方向错了程序本体的加密只能防源码泄露而要让人无法搬走运行就必须把授权绑定到机器特征上。License控制 机器指纹采集 授权文件签名校验 有效期校验三者缺一不可。常见的错误设计是只有“到期时间”。你把授权文件放到另一台电脑上时间没到就能跑——这就是没有环境绑定的漏洞。另有一个错误是只做“用户名 密码”验证这相当于没有验证密码一泄露全盘崩。正确做法是程序在启动时读取本机指纹拼上授权文件里的有效期用公钥验签。私钥留在你手上用户拿到的 License 文件经过签名不可篡改。这个模型下程序被拷走不要紧指纹不匹配照样拒绝运行。4.2 机器指纹采集不要只取 MAC 地址MAC 地址可以通过注册表修改或spoofmac类工具伪造单用途不足。常见做法是组合三个维度import hashlib import uuid import platform import subprocess import os def get_machine_fingerprint() - str: # 1. Windows 下读取主板序列号Linux 下读取 machine-id try: if platform.system() Windows: out subprocess.check_output( wmic csproduct get uuid, shellTrue, textTrue, timeout8 ) board_id .join(out.split(\n)[1:]).strip() else: with open(/etc/machine-id, r) as f: board_id f.read().strip() except Exception: board_id unknown_board # 2. MAC 地址可伪造仅作辅助 mac uuid.getnode() mac_str :.join((%012x % mac)[i:i2] for i in range(0, 12, 2)) # 3. 磁盘序列号Linux 上可通过 /sys/class/block/ 下的设备信息获取 disk_serial unknown_disk if platform.system() Windows: try: out subprocess.check_output( wmic diskdrive get serialnumber, shellTrue, textTrue, timeout8 ) disk_serial .join(out.split(\n)[1:]).strip() except Exception: pass raw f{board_id}|{mac_str}|{disk_serial} return hashlib.sha256(raw.encode(utf-8)).hexdigest()代码背后的考虑是任何一个单一维度都可以伪造但三个一起伪造的成本远高于 License 本身的价格。wmic在最新 Windows 中被移除时命令会抛异常程序会自动降级到unknown_board这会导致之前签发的 License 失效所以生产环境建议换成 PowerShell 的Get-CimInstance或直接读注册表HKLM\HARDWARE\DESCRIPTION\System\BIOS。拿到指纹后你不需要把原始的主板号存下来只保存哈希值。签发 License 时把这份哈希放进去。4.3 授权文件的签发与校验RSA 签名绝不用对称密钥License 文件的本质是一段 JSON签名后 base64。签发端是内部脚本要有私钥校验端是被编译的 Python 程序只带公钥。公钥泄密影响不大私钥泄密等于全盘崩溃。# 签发脚本build_license.py仅在自己机器上运行 import json import base64 from Crypto.Signature import pkcs1_15 from Crypto.Hash import SHA256 from Crypto.PublicKey import RSA # 私钥从环境变量读取避免写死在脚本里 private_key RSA.import_key(open(license_private.pem).read()) payload { client: 某客户名称, machine_fingerprint: 在这里粘贴程序返回的机器指纹, expire_at: 2025-12-31 23:59:59, features: [module_a, module_b] } body json.dumps(payload, sort_keysTrue).encode(utf-8) h SHA256.new(body) signature pkcs1_15.new(private_key).sign(h) license_content { payload: base64.b64encode(body).decode(), signature: base64.b64encode(signature).decode() } with open(license.dat, w) as f: f.write(json.dumps(license_content))校验端放在core/lic_verify.py中核心逻辑如下import json import base64 from Crypto.Signature import pkcs1_15 from Crypto.Hash import SHA256 from Crypto.PublicKey import RSA from datetime import datetime # 公钥嵌入代码中为了加大逆向难度可拆成多段拼接 public_key_pem -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY----- def verify_license(lic_path: str, fingerprint: str) - dict: with open(lic_path, r, encodingutf-8) as f: data json.load(f) body base64.b64decode(data[payload]) signature base64.b64decode(data[signature]) digest SHA256.new(body) public_key RSA.import_key(public_key_pem) try: pkcs1_15.new(public_key).verify(digest, signature) except (ValueError, TypeError): raise RuntimeError(签名校验失败授权文件可能被篡改) payload json.loads(body) # 指纹比对防止 License 迁移 if payload[machine_fingerprint] ! fingerprint: raise RuntimeError(授权文件与当前机器不匹配) # 有效期校验注意要使用 UTC 时间 expire_at datetime.strptime(payload[expire_at], %Y-%m-%d %H:%M:%S) if datetime.utcnow() expire_at: raise RuntimeError(授权已过期) return payloadverify_license()在程序入口处调用一次在核心算法每次执行前再校验一次。两段校验都做才能避免有人只跳过入口判断直接调用底层方法。实际项目中把verify_license改名为load_config、返回值经过另一层封装模拟正常配置读取能有效提高静态分析时的定位成本。4.4 License 文件格式与校验流程速查表字段类型说明缺失后果machine_fingerprintstring机器指纹哈希无法绑定环境expire_atstring过期时间UTC无法控制有效期featuresarray功能点开关无法做分级授权payloadbase64JSON 的 base64 编码无法携带授权信息signaturebase64payload 的 RSA 签名授权内容可被篡改校验流程固定为“解 base64 → 公钥验签 → 比对指纹 → 检查时间”顺序不可调换。先验签再比对指纹防止有人在 License 里注入钓鱼字段。如果把指纹比对放在验签前解析 payload 时可能被攻击者塞入恶意键值配合某些老版本 json 库的二次解析特性存在被绕过的风险。4.5 在线验证和离线验证怎么选离线验证不需要网络但吊销困难——客户拿到 License 后永远不会再联系你除非极短有效期配合强制续期。在线验证每个一段时间上报一次状态适合年费制产品。在线验证的标准接口可以非常简单import requests def online_check(license_key: str): resp requests.post( https://license.example.com/verify, json{key: license_key}, timeout5 ) if resp.status_code 200: return resp.json()[valid] return False注意requests如果不带timeout在网络不通时整个程序会卡死。生产环境里应当先做一次本机离线校验网络不通时给予 24~48 小时缓存宽限而不是直接拒绝运行。常见做法是在线验证成功后把“最近验证时间”写进本地状态文件下次离线启动时检查这个时间如果没超过宽限期就放行。5. 抗破解进阶时间防回拨、自校验与验证命令5.1 反时间回拨别只信datetime.now()把系统时间改回 2020 年很多 License 逻辑直接失效。加一道状态文件是低成本又有效的办法import os, json, datetime from pathlib import Path state_dir Path(os.environ[APPDATA]) / YourApp state_dir.mkdir(exist_okTrue) state_file state_dir / .runtime_state def stamp_time(): now datetime.datetime.utcnow() # 上一次过期时间如果本次时间比历史记录早说明被回拨 if state_file.exists(): last_expire json.loads(state_file.read_text()).get(last_expire) if last_expire and now datetime.datetime.fromisoformat(last_expire): raise RuntimeError(检测到系统时间被回拨) state_file.write_text(json.dumps({last_expire: now.isoformat()})) stamp_time()写路径要隐藏。%APPDATA%下的目录名称改成企业名文件权限最好设为只读避免普通用户直接打开修改。攻击者把时间改回去这个文件里的时间戳会成为唯一参照不建议把它跟 License 文件放在一起分开目录可以增加一点搜索成本。5.2 编译后自校验把校验代码编译进同一个二进制第 3 章用 Nuitka 编译时core/lic_verify.py已经被编译进launcher的机器码中。不要把它单独留在源码目录里再打包。编译完成后验证一下目标机器上没有任何.py或.pyc残留find build_out/ -name *.py -o -name *.pyc如果发现有.pyc文件说明 Nuitka 的--include-package参数没有生效全部模块。这种情况先检查core包__init__.py是否存在Nuitka 对中文目录名和含横线的包名支持都会打折扣要求用户把包名改成合法标识符不能用my-core。5.3 验证编译产物是否包含 LICENSE 公钥确认公钥真的被打进了产物而不是从外部配置文件读取strings build_out/launcher | grep BEGIN PUBLIC KEY | wc -l输出为1表示公钥已嵌入。注意公钥本身不算机密但如果技术人员用这个命令一搜就能找到说明代码中字符串特征过于明显。常见做法是把公钥 base64 后再反向切片存入三段拼接的字符串变量中运行时才组合。5.4 验证完整流程模拟篡改、迁移与时间回拨# 1. 正常运行验证签名 ./launcher --check # 2. 篡改 license.dat 中任意一个字符程序应拒绝启动 echo garbage license.dat ./launcher --check # 预期输出签名校验失败 # 3. 将 license.dat 复制到另一台机器应提示机器指纹不匹配 # 4. 将系统时间改回三个月前应提示检测到系统时间被回拨 # 5. 如果定义了宽限机制断网后应提示宽限剩余天数架构上预留一个--check隐藏参数在怀疑客户环境不兼容时远程指导对方自查能节省大量工单沟通。校验输出统一走 stderr便于服务端脚本捕获。最后提醒一个细节给 License 续期时不要直接修改旧文件追加时间而是重新用私钥签一个新文件替换。只要有人改动了 payload 里的任何一个字节解出的 JSON 会被重新序列化与原有签名的摘要不一致自动触发失败。把旧的license.dat改名备份为.bak再递送新文件客户侧要留心覆盖权限避免因文件被只读占用导致校验失败。整个方案的核心思路是源码用 Nuitka 编译成机器码授权用 RSA 签名绑定机器指纹启动时做多层校验运行时用状态文件防回拨。三层各自独立只要其中两层有效破解成本就会高于重新购买。对绝大多数商业授权场景来说这套设计的防护强度已经超过了常见依赖 obfuscator 单点加壳的方案。本文还有配套的精品资源点击获取