license激活码需用私钥对含product_id、expire_time、max_cpu_count及salt混淆的hardware_hash等字段的结构化载荷签名，再base64url编码；禁用md5/sha1，强制sha256+；硬件指纹须多源组合并加扰动防虚拟机复用；公钥须拆分隐藏、动态拼接；验证流程须先校验硬件绑定再验签，且全程静默、统一错误码。
License 激活码怎么生成才防批量伪造
离线 License 的核心不是“藏密钥”，而是让激活码本身携带可验证的结构化信息，且无法被逆向推导出签发逻辑。直接拼接时间戳+硬件指纹+随机数再哈希，等于把钥匙挂在门把手上——攻击者只要跑通一次 GetHardwareId() 和签名流程，就能自动生成有效码。
正确做法是：用私钥对结构化载荷（如 JSON 字符串）做 RSA_sign() 或 ECDSA_sign()，再 Base64Url 编码。载荷必须包含：product_id、expire_time（Unix 时间戳）、max_cpu_count、hardware_hash（经 salt 混淆后的 SHA256，salt 不进载荷，只参与签名前计算）。不把 salt 放进载荷，是为了防止攻击者替换硬件字段后重算哈希。
- 别用 MD5/SHA1 做签名摘要——已被证明不安全，强制用
SHA256或更高 - 硬件指纹别只取 CPU ID 或主板序列号——Windows 下
WmiClient::GetSerialNumber("Win32_BaseBoard")常为空，建议组合VolumeSerialNumber+CPUInfo::GetCacheLineSize()+GetTickCount64() % 1000（加扰动防虚拟机快照复用） - 激活码字符串里不要出现
=或+——Base64Url 编码必须用-和_替代，否则 Windows 注册表或命令行解析会出错
离线环境下如何验证签名又不暴露公钥
公钥硬编码在程序里是常见错误。攻击者反编译一眼就看到 const unsigned char g_pubkey_der[] = {0x30, 0x82, ...}，接着用 OpenSSL 就能伪造任意签名。真正可行的是：把公钥 DER 数据拆成多段，分散藏在资源节、字符串常量、甚至函数栈帧偏移中，校验前动态拼接；更进一步，用 GetModuleHandleA(nullptr) 算当前模块基址，结合固定偏移定位公钥片段——ASLR 下地址会变，但偏移不变。
验证流程必须原子化：载荷解码 → 提取 hardware_hash → 本地重算硬件指纹 → 对比失败则直接拒绝 → 再调用 RSA_verify()。跳过硬件校验直接验签，等于允许同一激活码在任意机器上通过。
- OpenSSL 的
RSA_verify()要求传入NID_sha256，不能写NID_md5——即使公钥是 RSA-2048，摘要算法错配会导致返回0且不报错 - 验证失败时不要返回具体原因（比如 “hardware mismatch” 或 “signature invalid”）——统一返回
ERROR_LICENSE_INVALID，避免给逆向者侧信道 - 别在验证函数里打印日志或弹窗——Release 版应完全静默，所有调试路径用
#ifdef DEBUG_LICENSE隔离
怎么防止用户复制激活码到另一台机器
纯靠硬件指纹绑定还不够。虚拟机、远程桌面、Docker 容器会让 GetAdaptersAddresses() 返回空或重复 MAC，导致合法用户反复激活失败。解决方案是引入“软绑定”：首次激活时，将签名载荷里的 hardware_hash 和当前机器实际算出的 local_hash 做异或，存进注册表 HKEY_CURRENT_USER\Software\MyApp\binding_seed；后续每次启动，读 seed 并与新算的 local_hash 异或，结果必须等于原始 hardware_hash。这样即使硬件值漂移，只要漂移模式稳定（比如 VMware 总是返回固定假 MAC），seed 就能补偿偏差。
- 注册表路径必须用
HKEY_CURRENT_USER，不能写HKEY_LOCAL_MACHINE——普通用户无权写后者，激活必然失败 - binding_seed 必须加密存储——用
CryptProtectData()（Windows）或SecKeychainItemCreateFromContent()（macOS），密钥来源设为当前用户 SID，防止提权后导出 - 不检查管理员权限——离线 License 系统必须支持标准用户运行，否则企业客户部署时会被策略拦截
ECDSA 比 RSA 更适合嵌入式 License 吗
是，但只在满足两个前提时成立：目标平台有硬件加速的 ECC 指令（如 ARMv8.2+ 的 sha256 + sm3 扩展），且你用的是 secp256r1 而非 secp384r1。RSA-2048 签名验签慢、密钥大（公钥 DER 约 300 字节），而 secp256r1 公钥仅 65 字节，ECDSA_verify() 在 Cortex-A72 上比 RSA_verify() 快 3.2 倍。但 x86_64 桌面端差异不大，且 OpenSSL 对 ECDSA 错误处理更隐蔽——比如私钥格式错，EC_KEY_new_by_curve_name() 返回非空指针但后续 ECDSA_sign() 失败，容易漏判。
- 别自己实现曲线运算——用 OpenSSL 1.1.1+ 或 BoringSSL，它们已修复
ECDSA_SIG_set0()的内存泄漏 - 生成密钥时必须用
EC_KEY_generate_key()，不能从文件读 PEM 后手动 set_group——某些旧版 OpenSSL 会忽略曲线参数校验 - 激活码长度会变短：RSA-2048 签名 256 字节 → Base64Url 后约 344 字符；secp256r1 签名 64 字节 → Base64Url 后仅 88 字符，更适合输入场景
最麻烦的从来不是算法选型，而是硬件指纹在不同 OEM 主板、云主机、WSL 环境下的行为一致性——没在戴尔 Precision、MacBook Pro M2、Azure Dsv5 三台机器上各跑 200 次 GetSystemFirmwareTable() 并统计失败率，就别谈“高可靠性”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
