开发工具应用安全【免费下载链接】pyarmorA tool used to obfuscate python scripts, bind obfuscated scripts to fixed machine or expire obfuscated scripts.项目地址https://gitcode.com/gh_mirrors/py/pyarmor点击查看免费下载本篇技术指南以 Pyarmor 的reg命令体系为核心系统讲解从激活文件activation file到注册文件registration file的完整授权链路覆盖 Basic/Pro 在线授权、CI/CD 流水线授权、Group License 离线设备授权以及 Docker 容器鉴权等真实场景。读者学完后将能独立完成 Pyarmor 的初次注册、多设备注册、群组设备文件生成、设备注册文件签发、CI regfile 申请与升级迁移并理解每个文件在底层源码中的落盘与校验逻辑。前置条件Prerequisite在使用任何许可证之前需要先确认满足以下四项条件一份激活文件activation file即购买 Pyarmor License 后通过注册邮箱收到的pyarmor-regcode-xxxx.txt购买前请参考 licenses 选择正确的许可证类型一台已安装Pyarmor 9.0的设备可用的互联网连接初次注册与部分授权校验需要连接 Pyarmor License Server一个将要与该许可证绑定的产品名product name。从源码角度看reg命令的完整入口定义在 src/cli/main.py其中-p/--product参数专门用于将许可证绑定到该产品且注册文件参数FILE明确接受pyarmor-regcode-xxx.txt或pyarmor-regfile-xxxx.zip两种形式。而激活文件的解析逻辑位于 src/cli/register.py它要求文件为纯文本、内容以Dear开头用于提取注册人姓名并包含一行长度为 192 且无换行的激活码否则会抛出invalid activation file错误。初次注册Initial Registration任何许可证都需要通过激活文件向 Pyarmor License Server 请求注册文件这是整个授权链路的第一步$ pyarmor reg -p XXX pyarmor-regcode-xxxx.txt其中-p用于为这份许可证指定产品名请将XXX替换为真实的产品名如果是非商业用途请将其替换为non-profits。初次注册成功后会在当前路径下同时生成一份注册文件pyarmor-regfile-xxxx.zip。这份文件用于在其他机器上进行后续注册必须妥善保管。需要特别牢记的规则激活文件一次性生效初次注册完成后pyarmor-regcode-xxxx.txt即失效不得再次使用产品名不可更改初次注册完成后产品名无法再修改注册文件务必备份请小心备份pyarmor-regfile-xxxx.zip一旦丢失Pyarmor 官方不负责保留此许可证也没有失物招领服务。源码中的初次注册流程对应WebRegister.register()方法src/cli/register.py先通过parse_keyfile()解析激活文件再拼接注册 URL 向服务器发起请求响应成功后写入注册文件随后打印重要提示Import Notes备份激活文件但不再使用它、用注册文件进行后续注册、不要将注册文件用于 docker 与 CI/CD 流水线。产品名尚未确定时TBD 占位当产品仍处于开发阶段、产品名尚未确定时可以在初次注册时将产品名设置为TBD$ pyarmor reg -p TBD pyarmor-regcode-xxxx.txt随后必须在6 个月内用以下命令设置真实产品名$ pyarmor reg -p XXX pyarmor-regcode-xxxx.txt如果 6 个月后仍未修改产品名会被自动设置为non-profits且无法再更改。这一逻辑在源码中有双重印证其一parse_token()在解析许可证 token 时若产品字段为空或为TBD会将显示的产品名统一标记为non-profits(TBD)src/cli/register.py其二WebRegister.prepare()在查询服务器返回的信息中如果产品为空或TBD会打印 If not change TBD to product name in 6 months, it will be set to non-profits automatically 的警告src/cli/register.py。另外需要注意对于Group LicenseTBD不是合法的产品名。源码中prepare()明确做了校验——当服务器返回的产品为TBD且许可证类型为GROUP时会抛出TBD is invalid product name for group license错误src/cli/register.py。使用 Pyarmor Basic / Pro 许可证Basic 与 Pro 的用法本质相同都遵循一次初始注册 多设备注册的模式参照「初次注册」章节先获得注册文件pyarmor-regfile-xxxx.zip使用注册文件在其他设备上注册 Pyarmor。把注册文件拷贝到其他机器后运行$ pyarmor reg pyarmor-regfile-xxxx.zip检查注册信息$ pyarmor -v注册成功后后续所有混淆操作都会自动应用此许可证并且每次混淆都需要在线进行许可证校验Basic 与 Pro 均为在线校验模式对应源码 src/cli/register.py 中* Need verify license online when obfuscating scripts的提示。使用要点该许可证最多可在100 台设备上注册每台设备注册一次即可不要在每次混淆前都执行注册不要在 CI/CD 流水线或 docker 容器中直接使用注册文件注册因为每次运行都会被计为一台新设备详见 ci。从源码角度.zip注册文件的落盘逻辑由Register.register_regfile()实现src/cli/register.py它会从 zip 包中解出license.lic与.pyarmor_capsule.zip存入注册路径并根据包内是否含group.tokens、ci.token、group.info、reg.info等标记分发到不同的授权分支若这些标记都不存在则提示许可证尚未适配 Pyarmor 9 并引导用户查看升级说明。使用 CI License9.0 新增版本要求Pyarmor 9.0versionadded:: 9.0CI License 专门用于 CI/CD 流水线场景。核心规则是不要直接在 CI/CD 流水线中使用pyarmor-regfile-xxxx.zip它只用来申请 CI regfile。本地申请 CI regfile参照「初次注册」获得注册文件后在本地设备运行以下命令申请一份 CI regfilepyarmor-ci-xxxx.zip$ pyarmor reg -C pyarmor-regfile-xxxx.zip在本地机器检查 CI 许可证信息$ pyarmor --home temp reg pyarmor-ci-xxxx.zip在 CI/CD 流水线中注册在 CI/CD 流水线中添加两个步骤用 CI regfile 注册 Pyarmor# 请将 9.X.Y 替换为当前 Pyarmor 版本号 pip install pyarmor9.X.Y pyarmor reg pyarmor-ci-xxxx.zip检查流水线中的注册信息$ pyarmor -vCI License 注意事项不要在 CI/CD 流水线中申请 CI regfile申请动作必须在本地完成CI regfilepyarmor-ci-xxxx.zip大约在360 天后过期CI regfile 可能在未来的 Pyarmor 版本中失效一旦 CI regfile 失效需要申请新的一份许可证最多可以申请100 个 CI regfile。重要CI License在本地设备上不生效。即使在 CI/CD 流水线中如果 runner 自带磁盘即不是 docker 容器CI License 同样无法工作此时应改用 Pro License。上述限制在源码中有清晰体现request_ci_regfile()会校验注册文件中是否含有reg.info缺失时报 this license may be out of date随后从服务器获取CITOKEN:响应头并以ci.token条目写入新生成的pyarmor-ci-xxxx.zipsrc/cli/register.py。而register_regfile()中如果发现 zip 包内含reg.info且类型为C会直接拦截并提示该文件仅用于申请 ci regfilepyarmor reg -C file防止误用src/cli/register.py。检查设备是否适用于 Group LicenseGroup License 依赖设备 machine id 的稳定性因此在购买/使用前应当先验证目标设备是否可用先在该设备安装Pyarmor 8.4.0 试用版用以下命令获取 machine id$ pyarmor reg -g 1 ... INFO current machine id is mc92c9f22c732b482fb485aad31d789f1 INFO device file has been generated successfully重启该设备再次执行同一命令检查 machine id 是否一致如果每次重启后 machine id 都相同说明 Group License 可以在该设备上工作否则不适用。对于 docker 容器应按上述方法检查docker 宿主机。只有宿主机能使用 Group License才能在该宿主机上运行无限数量的 docker 容器参见下文「在离线设备运行无限 docker」一节。如果 docker 宿主机的 machine id 在重启后发生变化那么任何 docker 容器内都无法使用 Group License。总体而言大多数物理机、云服务器以及使用相同磁盘镜像的虚拟机如 Qemu、VirtualBox、VMware都能与 Group License 兼容而 CI/CD 流水线中的大多数 runner 无法使用 Group License。从源码看generate_group_device()会调用底层Pytransform3.get_hd_info()采集硬件信息并写入设备文件src/cli/register.py用于计算 machine id 的设备标志位可通过配置group_device_flag调整其默认值为 22定义于 src/cli/default.cfg。使用 Group License版本要求Pyarmor 8.2versionadded:: 8.2每个Pyarmor Group可包含100 台离线设备每台设备拥有独立的编号1~100。只有重启后 machine id 不变的设备才能作为群组设备参考上文「检查设备」一节。需要特别注意的是已分配的设备编号永远不会释放。如果某台设备被重装系统就需要为其分配新的编号。基本步骤使用激活文件pyarmor-regcode-xxxx.txt完成初次注册绑定产品名并生成注册文件分别在每台离线设备上生成群组设备文件使用注册文件 群组设备文件生成设备注册文件使用设备注册文件在离线设备上注册 Pyarmor。注设备注册文件与指定设备绑定每台设备拥有各自的设备 regfiledevice regfile。初次注册购买 Pyarmor Group 后激活文件pyarmor-regcode-xxxx.txt会发送到注册邮箱。初次注册需要联网且 Pyarmor 8.2。假设产品名为XXX运行$ pyarmor reg -p XXX pyarmor-regcode-xxxx.txt初次注册完成后会生成注册文件pyarmor-regfile-xxxx.zip。生成群组设备文件Group device file在每台离线设备上安装 Pyarmor 8.2并生成群组设备文件。例如在 1 号设备上运行$ pyarmor reg -g 1 INFO Python 3.12.0 INFO Pyarmor 8.4.7 (trial), 000000, non-profits INFO Platform darwin.x86_64 INFO generating device file .pyarmor/group/pyarmor-group-device.1 INFO current machine id is mc92c9f22c732b482fb485aad31d789f1 INFO device file has been generated successfully该命令会生成群组设备文件pyarmor-group-device.1。为确保 Group License 能在这台设备上工作请重启设备后再次运行$ pyarmor reg -g 1 ... INFO current machine id is mc92c9f22c732b482fb485aad31d789f1 ...确认重启后 machine id 一致。因为 Group License 与设备绑定所以 machine id 在重启后必须保持不变若发生变化则 Group License 不适用于该设备。对于 VM、WSLWindows Subsystem Linux或任何其他系统请查阅相应文档配置网络与硬盘确保网卡 MAC 地址和硬盘序列号固定。如果它们是可变的Group License 将无法在该系统中工作。源码中cmd_reg()对-g/--device的处理做了分流当传入设备编号且未提供注册文件时直接调用generate_group_device()生成设备文件src/cli/main.py当同时提供注册文件时则进入request_device_regfile()请求设备注册文件src/cli/main.py。同时-g的参数范围被严格限制为 1~100choicesrange(1, 101)。生成离线设备注册文件生成离线设备注册文件需要互联网连接、Pyarmor 8.2、群组设备文件pyarmor-group-device.1、Group License 的注册文件pyarmor-regfile-xxxx.zip。将群组设备文件pyarmor-group-device.1拷贝到初次注册设备或任何有网络且持有注册文件的电脑上该文件必须存放在.pyarmor/group/路径下然后运行以下命令生成设备注册文件pyarmor-device-regfile-xxxx.1.zip$ mkdir -p .pyarmor/group $ cp pyarmor-group-device.1 .pyarmor/group/ $ pyarmor reg -g 1 /path/to/pyarmor-regfile-xxxx.zip设备注册文件pyarmor-device-regfile-xxxx.1.zip与设备文件pyarmor-group-device.1中的 machine id 绑定。注意如果新版本 Pyarmor 修复了设备重启后 machine id 变化的 bug则需要用新版 Pyarmor 为这台设备生成新的设备文件pyarmor-group-device.2并用新版 Pyarmor 生成新的设备注册文件pyarmor-device-regfile-xxxx.2.zip。由于设备编号1已被占用此时需使用下一个编号2。也就是说一台设备可能占用多个设备编号。由于共有 100 个编号可用一般情况下这不是问题。在离线设备上注册 Pyarmor设备注册文件生成后将其拷贝到对应设备运行以下命令注册 Pyarmor$ pyarmor reg /path/to/pyarmor-device-regfile-xxxx.1.zip INFO Python 3.12.0 INFO Pyarmor 8.4.7 (trial), 000000, non-profits INFO Platform darwin.x86_64 INFO register /path/to/pyarmor-device-regfile-xxxx.1.zip INFO machine id in group license: mc92c9f22c732b482fb485aad31d789f1 INFO got machine id: mc92c9f22c732b482fb485aad31d789f1 INFO this machine id matchs group license INFO This license registration information: License Type : pyarmor-group License No. : pyarmor-vax-006000 License To : Tester License Product : btarmor BCC Mode : Yes RFT Mode : Yes Notes * Offline obfuscation注意日志中的两条关键信息machine id in group license设备注册文件中绑定的 machine id与got machine id本设备的 machine id两者必须匹配否则该设备注册文件无法使用需要为该设备重新生成。检查注册信息$ pyarmor -v注册成功后后续所有混淆操作都会自动应用此 Group License且每次混淆无需在线许可证校验Group License 为离线混淆模式对应源码中* Offline obfuscation的提示src/cli/register.py。从源码看_register_offline_license()会遍历一组支持的 machine flagMACHFLAGS 22, 21, 18, 20, 16, 11src/cli/register.py逐一计算本机 machine id与注册文件tokens/machid条目比对匹配则提取群组 token不匹配则尝试以 docker 容器身份连接宿主机鉴权src/cli/register.py。在离线设备上运行无限 docker 容器版本要求Pyarmor 8.3versionadded:: 8.3Group License 支持在宿主机上运行无限数量的使用默认 bridge 网络且未高度定制的 docker 容器这些容器与宿主机共用同一份设备注册文件。工作原理每个 docker 宿主机被视为一台离线设备必须按上文步骤完成注册在 docker 宿主机上启动一个auth-serverpyarmor-auth监听来自 docker 容器的鉴权请求在 docker 容器内运行 Pyarmor 时它会向宿主机上的 auth-server 发送鉴权请求并验证宿主机返回的结果。Linux Docker 宿主机以下是一套可实践的完整配置示例Docker 宿主机Ubuntu x86_64Python 3.8Docker 容器Ubuntu x86_64Python 3.11宿主机上的前置条件离线设备注册文件pyarmor-device-regfile-xxxx.1.zip见上文Pyarmor 8.4.1首先将以下文件拷贝到 docker 宿主机pyarmor-8.4.2.tar.gzpyarmor.cli.core-5.4.1-cp38-none-manylinux1_x86_64.whlpyarmor.cli.core-5.4.1-cp311-none-manylinux1_x86_64.whlpyarmor-device-regfile-6000.1.zip然后在 docker 宿主机上执行$ python3 --version Python 3.8.10 $ pip install pyarmor.cli.core-5.4.1-cp38-none-manylinux1_x86_64.whl $ pip install pyarmor-8.4.1.tar.bgz接下来启动pyarmor-auth监听来自 docker 容器的请求$ pyarmor-auth pyarmor-device-regfile-6000.1.zip 2023-06-24 09:43:14,939: work path: /root/.pyarmor/docker 2023-06-24 09:43:14,940: register pyarmor-device-regfile-6000.1.zip 2023-06-24 09:43:15,016: listen container auth request on 0.0.0.0:29092不要关闭此控制台另开一个控制台运行 docker。Linux 容器需要附加--add-hosthost.docker.internal:host-gateway参数$ docker run -it --add-hosthost.docker.internal:host-gateway python bash root86b180b28a50:/# python --version Python 3.11.4 root86b180b28a50:/#在宿主机上打开第三个控制台将文件拷贝进容器$ docker cp pyarmor-8.4.1.tar.gz 86b180b28a50:/ $ docker cp pyarmor.cli.core-5.4.1-cp311-none-manylinux1_x86_64.whl 86b180b28a50:/ $ docker cp pyarmor-device-regfile-6000.1.zip 86b180b28a50:/在 docker 容器内用同一份设备注册文件注册 Pyarmorroot86b180b28a50:/# pip install pyarmor.cli.core-5.4.1-cp311-none-manylinux1_x86_64.whl root86b180b28a50:/# pip install pyarmor-8.4.1.tar.gz root86b180b28a50:/# pyarmor reg pyarmor-device-regfile-6000.1.zip root86b180b28a50:/# pyarmor -v一切正常的话会打印出 Group License 信息。再用一个简单脚本测试root86b180b28a50:/# echo print(hello world) foo.py root86b180b28a50:/# pyarmor gen --enable-rft foo.py当需要校验许可证时容器会向宿主机发送请求。pyarmor-auth控制台应打印来自容器的鉴权请求如果没有任何请求请检查 docker 网络配置确保宿主机与容器的 IPv4 地址处于同一网段。例如在容器内root86b180b28a50:/# ifconfig -a eth0: flags4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 172.17.0.2 netmask 255.255.0.0 broadcast 172.17.255.255 ...在宿主机上$ ifconig -a docker0: flags4099UP,BROADCAST,MULTICAST mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ...MacOS Docker 宿主机当 docker 宿主机是 MacOS 时略有不同因为 docker 容器运行在 Linux VM 中而非直接运行在 MacOS 上。一种解决方案是在Linux VM中运行pyarmor-auth。此时应将这台Linux VM 视为离线设备为 Linux VM而不是 MacOS生成设备注册文件并以附加参数启动容器$ docker run --add-hosthost.docker.internal:172.17.0.1 ...这种情况下可能需要对 Linux VM 做一些额外配置以确保 machine id 保持固定官方 issue #1542 有更详细的讨论。Windows Docker 宿主机对于 Windows docker 宿主机先检查 Windows 网络配置C: ipconfig Ethernet adapter vEthernet (WSL): Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::8984:457:2335:588e%28 IPv4 Address. . . . . . . . . . . : 172.22.32.1 Subnet Mask . . . . . . . . . . . : 255.255.240.0 Default Gateway . . . . . . . . . :如果存在与 docker 容器同网段的 IPv4 地址例如172.22.32.1那就很简单把 Windows 本身作为离线设备在其上运行pyarmor-auth并以附加参数启动容器$ docker run --add-hosthost.docker.internal:172.22.32.1 ...无论如何pyarmor-auth必须监听在与 docker 容器同网段的任意 IPv4 地址上。如果 Windows 没有可用的 IPv4 地址另一种方案是在WSL中运行pyarmor-auth此时应把 WSL 作为离线设备。例如# 创建一个带自定义子网的 docker 桥接网络 docker network create --subnet172.17.0.0/16 pyarmor-net # 在指定网络上运行容器并把 host.docker.internal 指向网关 docker run --network pyarmor-net --add-host host.docker.internal172.17.0.1 ...这样做是为了显式保证许可证校验要求宿主机与容器处于同一子网而不仅仅是网络可达。另一种方案是以--networkhost运行 docker这能确保容器与宿主拥有相同的网络掩码。排障当出现问题时的检查清单检查 docker 容器网络root86b180b28a50:/# ifconfig -a eth0: flags4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 172.17.0.2 netmask 255.255.0.0 broadcast 172.17.255.255 ... root86b180b28a50:/# ping host.docker.internal PING host.docker.internal (172.17.0.1) 56(84) bytes of data. 64 bytes from host.docker.internal (172.17.0.1): icmp_seq1 ttl64 time0.048 ms ...如果ping不通请检查 docker 宿主机网络MacOS 宿主机还要检查 Linux VM 网络Windows 宿主机还要检查 WSL 网络。同时确保host.docker.internal的 IPv4 地址与eth0上例中为172.17.0.2同网段。上例中它是172.17.0.1所以没问题。若不同网段同样需要检查宿主机网络MacOS 可能需要改在 Linux VM 中运行pyarmor-authWindows 可能需要改在 WSL 中运行。总之请配置 docker 宿主机/容器网络使pyarmor-auth能监听在与容器同网段的任意 IPv4 地址上。检查宿主机 Group License 是否正常$ pyarmor -d reg pyarmor-device-regfile-6000.1.zip $ pyarmor -v如果在 Linux VM 或 WSL 中运行pyarmor-auth请确认 Group License 能在 Linux VM 或 WSL 中工作必要时为 Linux VM 或 WSL 生成新的设备注册文件。从源码看pyarmor-auth是一个独立的鉴权守护进程实现位于 src/cli/docker.py。它默认监听0.0.0.0:29092端口常量定义于 src/cli/docker.py通过DockerAuthHandler处理三类协议包PADH宿主机 machine id 查询、PADI外层密钥、PADK运行时密钥并为容器动态生成 runtime keysrc/cli/docker.py。容器侧则通过环境变量PYARMOR_DOCKER_HOST默认host.docker.internal和端口 29092 连接宿主机src/cli/register.py。在同一台设备上使用多个 Pyarmor 许可证一般来说注册信息存储在 Pyarmor 的Home Path中默认值为~/.pyarmor。这意味着所有 Python 虚拟环境共享同一份注册信息在同一台设备上注册其他 Pyarmor 许可证可能不生效。当需要在一台机器上使用多个 Pyarmor 许可证时应为每个许可证指定不同的路径。例如$ pyarmor --home ~/.pyarmor1 reg pyarmor-regfile-2051.zip $ pyarmor --home ~/.pyarmor1 gen project1/foo.py $ pyarmor --home ~/.pyarmor2 reg pyarmor-regfile-2052.zip $ pyarmor --home ~/.pyarmor2 gen project2/foo.py--home选项在源码中定义于 src/cli/main.py--home为隐藏帮助参数并由get_home_paths()解析。Home Path 的实际落盘结构定义在 src/cli/context.pyhome_path为许可证工作目录reg_path是注册信息目录许可证 token.license.token、群组 token.license.group.token、license.lic与.pyarmor_capsule.zip均存放在此目录下src/cli/context.py。因此更换--home即相当于把整套注册状态隔离到独立沙盒中。升级 Pyarmor 之后需要做什么一般情况下升级 Pyarmor 后无需做任何操作原有注册信息依然有效。但在以下版本节点有重要变化Pyarmor 8.0Pyarmor 7 的旧许可证不适用于 8.x部分旧许可证可以免费升级为 Basic License参见下文「升级旧许可证」旧许可证不能升级为 Pro 或 Group License。Pyarmor 9.0在 CI/CD 流水线中的使用方式发生了重大变化Pyarmor Basic可免费升级到 Pyarmor 9若在 CI/CD 流水线中使用 Pyarmor请参考 ciPyarmor Pro若不在 CI/CD 流水线中使用可免费升级到 Pyarmor 9若在 CI/CD 流水线中使用则有两种选择继续使用 Pyarmor 8.x或升级到 Pyarmor 9 并购买新的 Pyarmor CI LicensePyarmor Group需要用 Pyarmor 9.0 为每台离线设备重新生成设备注册文件参见下文「升级到 Pyarmor 9」。Pyarmor 9.2从 9.0 升级到 9.2CI 与 Group 许可证均有变化若版本低于 9.0还需一并参考上文 9.0 的变化Pyarmor CI需要为新版本申请新的 ci regfile旧版本仍可使用旧文件。例如旧 ci regfilepyarmor-ci-8000.zip只用于旧版本升级到 9.2 后重新申请一份新的$ pyarmor reg -C pyarmor-regfile-8000.zip然后在新版本中使用新文件注意它不兼容任何更早版本。Pyarmor Group需要为新版本更新设备注册文件旧文件仍可用于旧版本。例如旧的 1 号设备文件pyarmor-device-regfile-6000.1.zip用于旧版本升级到 9.2 后申请新的$ pyarmor reg -g 1 /path/to/pyarmor-regfile-6000.zip然后在新版本中使用新文件同样不兼容任何更早版本。源码层面对升级约束有直接校验check_license_version()检测到旧版许可证rev1 且 features0时会给出明确提示——Group License 需要重新申请设备注册文件其他类型则弹出 Pyarmor 9 has big change on CI/CD pipeline 的交互确认src/cli/register.py而register_regfile()对不含任何新版标记的旧注册文件会直接阻止注册并引导查看 Pyarmor 9.0 升级说明src/cli/register.py。升级旧许可证Pyarmor 7 → Basic并非所有旧许可证Pyarmor 7都能升级到最新版本。旧许可证可免费升级为 Pyarmor Basic但必须同时满足以下条件同意新的 Pyarmor EULA最终用户许可协议许可证编号以pyarmor-vax-开头原始激活文件pyarmor-regcode-xxxx.txt仍然存在且使用次数不超过 100 次旧许可证在2023 年 6 月 1 日之前购买原则上在 Pyarmor 8 可用之后购买的旧许可证不能升级。如果升级失败请购买新许可证以使用最新版 Pyarmor。旧许可证不能升级为 Pyarmor Pro 和 Group。升级到 Pyarmor Basic 的操作步骤首先找到激活文件pyarmor-regcode-xxxx.txt购买许可证时发送到注册邮箱。接着安装 Pyarmor 8.2依据新 EULA每份许可证仅用于一个产品。假设该许可证将用于混淆产品XXX运行$ pyarmor reg -u -p XXX pyarmor-regcode-xxxx.txt检查升级后的许可证信息$ pyarmor -v升级成功后不要再使用激活文件pyarmor-regcode-xxxx.txt它已失效同时会生成一份新的注册文件pyarmor-regfile-xxxx.zip。在其他设备上使用这份新的注册文件注册 Pyarmor$ pyarmor reg pyarmor-regfile-xxxx.zip注册成功后所有混淆操作都会自动应用该许可证且每次混淆需要在线校验。如果旧许可证被多个产品使用主要是旧个人许可证升级后仅有一个产品可以继续使用其余产品需要购买新许可证。源码中-u/--upgrade参数会触发cmd_reg()内的升级分支只有.txt激活文件才允许升级.zip 文件会被拒绝见check_args()src/cli/register.py升级请求通过 URL 中的upgrade_to_basic1参数标识src/cli/register.py服务器返回后自动进入 Basic 帮助引导LicenseHelpersrc/cli/register.py。升级到 Pyarmor 91. Pyarmor Basic 与 Pyarmor Pro若许可证已在本设备注册$ pip install -U pyarmor首次执行混淆时会显示交互提示$ pyarmor gen foo.py ... Pyarmor 9 has big change on CI/CD pipeline If not using Pyarmor License in CI/CD pipeline Press c to continue Otherwise press h to check Pyarmor 9.0 Upgrade Notes Continue (c), Help (h), Quit (q):直接按c继续即可之后不会再出现该提示。这一交互逻辑正是check_license_version()的实现src/cli/register.py。若许可证未在本设备注册$ pip install -U pyarmor # 请将 XXX 替换为真实产品名 $ pyarmor reg -p XXX pyarmor-regcode-xxxx.txt保存并备份新的注册文件pyarmor-regfile-xxxx.zip然后在其他新设备上用该文件注册$ pyarmor reg pyarmor-regfile-xxxx.zip $ pyarmor -v如果激活文件使用次数过多请先安装 Pyarmor 8再升级到 Pyarmor 9。2. Pyarmor Group License需要先用 Pyarmor 9.0 重新生成设备注册文件$ pip install -U pyarmor然后按原流程生成设备注册文件。例如为 1 号设备生成pyarmor-device-regfile-6000.1.zip$ pyarmor reg -g 1 /path/to/pyarmor-regfile-6000.zip最后用新文件在离线设备上注册$ pyarmor reg pyarmor-device-regfile-6000.1.zip附录pyarmor reg命令参数速查以下参数定义可直接在 src/cli/main.py 中查到参数说明regfile位置参数pyarmor-regcode-xxx.txt激活文件或pyarmor-regfile-xxxx.zip注册文件可省略-p, --product NAME将许可证绑定到指定产品名仅用于初次注册的.txt文件-u, --upgrade升级旧 Pyarmor 许可证-g, --device ID群组许可证中的设备编号1~100仅提供编号时生成设备文件同时提供注册文件时生成设备注册文件-C, --CI为 CI 流水线申请许可证注册文件生成pyarmor-ci-xxxx.zip--buy在默认浏览器中打开购买链接--home PATH指定 Home Path默认~/.pyarmor用于多许可证隔离-d, --debug开启调试日志pyarmor-auth亦支持典型用法对照pyarmor reg—— 查看当前许可证信息源码分支见 src/cli/main.pypyarmor reg -p XXX xxx.txt—— 初次注册激活文件 产品名pyarmor reg xxx.zip—— 非初次注册直接应用注册文件此时不应再加-p源码会报 unwanted product name见 src/cli/main.pypyarmor reg -g 1—— 生成本机群组设备文件pyarmor-group-device.1pyarmor reg -g 1 pyarmor-regfile-xxxx.zip—— 为设备 1 生成设备注册文件pyarmor reg -C pyarmor-regfile-xxxx.zip—— 申请 CI regfilepyarmor reg -u -p XXX xxx.txt—— 升级旧许可证到 Pyarmor Basic。综上所述Pyarmor 的授权体系围绕激活文件 → 注册文件 → 设备/CI 派生文件层层展开Basic/Pro 面向在线单机与构建机CI License 面向流水线Group License 面向离线设备与 docker 集群。掌握reg命令的每一种形态与其底层文件落盘规则即可在任何部署环境中稳定、合规地使用 Pyarmor 进行脚本混淆。赞分享开发工具应用安全【免费下载链接】pyarmorA tool used to obfuscate python scripts, bind obfuscated scripts to fixed machine or expire obfuscated scripts.项目地址https://gitcode.com/gh_mirrors/py/pyarmor点击查看免费下载相关推荐PyArmor 许可证完全指南免费试用限制、个人/企业授权与注册流程PyArmor 许可证完全指南免费试用限制、个人/企业授权与注册流程 本文基于 PyArmor 仓库中 docs.7/license.rst 的许可证文档撰写开发工具应用安全TDengine TSDB 企业版激活指南激活码获取、ALER CLUSTER 激活与授权验证全流程TDengine TSDB 企业版激活指南激活码获取、ALER CLUSTER 激活与授权验证全流程 本文完整讲解如何在已部署的 TDengine TSDB数据库时序数据库物联网大数据实时分析云原生IoT设备安全认证终极指南Better Auth设备授权流程全解析IoT设备安全认证终极指南Better Auth设备授权流程全解析 在万物互联的零信任时代IoT设备安全认证已成为保护智能生态系统的首要防线。随着智能家居、认证鉴权后端身份认证上一篇ZeroBrane Studio Lua IDE 快速上手指南5分钟装好、跑通并调试第一个脚本下一篇如何为TPOT编写自定义config_dict配置字典自由定制搜索空间显著提速AutoML创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考