离线License防篡改的核心是绑定设备指纹、非对称签名与公钥验签三者不可拆分：用私钥对“硬件ID+有效期+功能掩码”签名，Base64URL编码；校验时仅依赖公钥验签，不硬编码密钥或逻辑。
License 激活码怎么生成才防篡改、难逆向
离线 License 的核心不是“加密字符串”，而是“绑定 + 签名 + 校验三者不可拆分”。直接 base64 或 AES 加密硬件指纹毫无意义——攻击者只要 patch 掉校验分支，或伪造签名验证函数返回 true，整个系统就失效。
真正有效的做法是：用私钥对「设备指纹 + 有效期 + 功能位掩码」做非对称签名，再把原始数据和签名一起编码为激活码。校验时只用公钥验签，不依赖任何本地密钥或硬编码逻辑。
-
设备指纹必须组合至少 3 类稳定标识（如主板序列号 + CPU ID + 磁盘卷标），避免单点失效；Windows 上慎用Win32_ComputerSystemProduct.UUID（虚拟机常为空） - 签名前的数据必须用固定格式序列化（推荐 CBOR 或紧凑 JSON），禁止自由拼接字符串——否则容易被重放或字段注入
- 激活码最终用 Base64URL 编码（非标准 Base64），避免在 URL/邮件中被截断或转义
用 OpenSSL 命令行快速生成签名校验流程
别急着写 C++ 代码，先用 OpenSSL 验证流程是否闭环。这是最容易卡住的环节：签名能生成，但 C++ 里验不过，90% 是 ASN.1 编码格式或填充方式不一致。
生成密钥对（2048 位足够，别盲目上 4096）：
立即学习“C++免费学习笔记（深入）”；
openssl genrsa -out license.key 2048 openssl rsa -in license.key -pubout -out license.pub
构造待签名数据（payload.json）：
{"hwid":"a1b2c3d4","exp":1735689600,"features":3}
签名并编码为激活码：
openssl dgst -sha256 -sign license.key -binary payload.json | openssl enc -base64 | tr '+/' '-_' | tr -d '\n'
注意：tr '+/' '-_' 是 Base64URL 关键，否则 C++ 的 EVP_VerifyFinal 会因填充错误返回 0
C++ 里用 OpenSSL 验签时最常踩的 3 个坑
OpenSSL C API 对内存和上下文管理极敏感，同一份公钥、同一段签名，在 Python 里秒过，C++ 里死活失败，大概率栽在这几个地方：
- 公钥加载必须用
PEM_read_bio_PUBKEY，不能用PEM_read_bio_RSAPublicKey——后者只支持传统 PKCS#1 格式，而openssl rsa -pubout默认输出的是 PKCS#8，类型不匹配直接导致EVP_VerifyInit失败 - 验签前必须调用
EVP_VerifyUpdate传入原始 payload 数据（不是 Base64 解码后的签名！），且数据长度要精确，末尾不能有多余换行或 BOM - Base64URL 解码后必须还原为原始二进制签名（
openssl enc -base64 -d不支持 URL 变体），建议用轻量函数处理：std::replace(s.begin(), s.end(), '-', '+'); std::replace(s.begin(), s.end(), '_', '/');再进BIO_new_mem_buf
离线激活码如何安全嵌入 C++ 程序而不暴露公钥
公钥不能硬编码为字符串字面量，也不能藏在资源段里——strings ./myapp | grep '-----BEGIN PUBLIC KEY' 一下就全出来。更隐蔽的做法是运行时动态拼接：
把公钥拆成 3 段，分别存于不同位置：
- 段 1：编译期计算哈希值，作为数组大小（如
char pub_key_1[SHA256_LEN]） - 段 2：从某张图片的末尾 256 字节读取（实际不解析图片，只当二进制容器）
- 段 3：用当前年月日异或混淆后存为字节数组，运行时再反向解出
最后用 memcpy 拼成完整 PEM 字符串，喂给 BIO_new_mem_buf。这不是防专业逆向，而是提高自动化提取门槛——让批量脱壳工具无法直接 dump 出有效公钥。
真正的难点不在加密强度，而在如何让校验逻辑本身难以被定位和跳过。比如把验签结果拆成多处判断，中间混入与业务逻辑强耦合的分支（如“只有验签通过且用户配置了 license_mode=offline 才加载插件”），让 patch 者不敢轻易 NOP 掉整块代码。
