软件加密工具选型工程笔记：技术栈、CI/CD 与国产化

这是“软件加密工具选型工程笔记”第 3 篇。这个系列把九项标准放进构建、测试和发布流程，同时保留必要的功能核对。本篇记录兼容性、集成与国产化的核对方法。

工程结论：平台兼容性要核对具体文件格式、编译器、运行时、操作系统、CPU 架构和后续处理；开发集成要验证命令行、配置复用、批处理与 CI/CD；国产化项目还需把系统版本、架构、部署方式和采购材料逐项确认。

先明确输入、输出和保护目标

“支持 Java”“支持 ARM”只说明方向，不代表当前构建产物已经适配。同一种语言可能生成不同文件格式，同一系统也有版本、架构、依赖库和部署方式差异。保护后的程序还要继续签名、打包、安装、二次链接或烧录，任何一个环节不匹配都可能阻止上线。

缺少具体版本或测试环境时，相关结论只能作为评估框架。项目评审时应补齐编译器、运行时、系统、CPU 架构、构建方式和目标设备。

把检查项整理成项目表

平台兼容性需要落实到具体产物和环境。下表列出进入测试前应补齐的信息。

核对层面	需要确认的问题
程序与文件格式	EXE、DLL、ELF、SO、Mach-O、JAR、Class、APK、AAB、IPA、脚本、静态库或目标文件是否支持
开发语言与程序类型	Native、.NET、Java、Python、Unity、移动应用等是否有对应方案
操作系统	Windows、Linux、macOS、Android、iOS、HarmonyOS 及国产操作系统的具体版本
CPU 架构	x86、x64、ARM32、ARM64、LoongArch、MIPS 等是否覆盖
编译与运行环境	编译器、解释器、运行时、开发引擎、框架和第三方依赖版本
后续处理	保护后能否签名、打包、安装、升级、二次链接、烧录并正常运行

兼容性结论必须绑定具体产物、版本和发布步骤。单独写“支持某语言”不足以支撑上线判断。

工程上需要拆开的几个环节

平台兼容性：按构建产物核对支持范围

平台兼容性应依据构建产物核对环境

先确认待保护文件，再核对它使用的语言、编译器和运行时，以及目标系统与 CPU 架构。产品增加新语言、新平台或新架构后，还要确认工具是否更新了支持范围，旧配置能否继续使用。

平台兼容性的产品能力与验证条件

Virbox Protector（VBP）的支持范围可按程序类型、系统和指令集初步核对。

支持维度	支持范围示例
程序类型	Native、.NET、Android APK/AAB/AAR、Unity、Python、macOS/iOS App、HarmonyOS SO/HAP、Java JAR/WAR/Class、静态库和目标文件
语言与框架	C/C++、Java/Kotlin、C#/J#、Swift/Objective-C、Python、PB/Delphi/VB/VC、Flutter、Golang
操作系统	Windows、Linux、macOS、Android/iOS、HarmonyOS、OpenWrt、欧拉、龙蜥、统信、麒麟
指令体系	x86/x64、ARM32/ARM64/Thumb、LoongArch、MIPS、Dalvik、JVM、MSIL

表中内容适合初筛。实际项目还要核对文件格式、编译器、运行时、框架版本和发布方式。

开发集成：把保护步骤接入构建和发布

源码标签与编译后保护分属两个步骤

SDK 标签写在源代码中，用于标记需要保护的对象；程序编译后，保护工具解析产物中的标签并执行策略。代码结构、编译方式或 Java 混淆流程变化后，标签可能无法按原方式解析，因此每次重大构建变化都要重新核对。

把保护步骤接入 CI/CD

常见顺序是：编译原始程序，调用命令行完成保护，检查退出状态，再签名或打包，随后执行功能、兼容性和性能测试，最后保存发布版本与本次配置。移动应用、静态库、目标文件和桌面软件的后续处理不同，流水线顺序应按产物类型设计。

开发集成的产品能力与验证条件

VBP 提供 GUI 和命令行方式。使用 SDK 标签时，应先在源代码中标记保护对象，再完成编译，由工具解析 PE、ELF、Mach-O 或 JAR 等产物中的标签并执行保护。代码结构、编译方式或 Java 混淆流程变化后，需要重新核对标签解析结果。

持续发布可按“编译原始程序、命令行保护、检查退出状态、签名或打包、执行回归测试、保存配置与发布版本”的顺序组织。移动应用、静态库、目标文件和桌面软件的后续处理不同，流水线不能共用一套未经验证的顺序。

合规性：把国产化适配落实到具体环境

国产化适配仍需核对合规要求

工具支持统信、麒麟、欧拉、龙蜥或 LoongArch、ARM 等环境，只能说明具备相应适配方向。项目若要求兼容认证、测评报告、资质证明或特定采购条款，还要按采购文件单独核对。

合规性的产品能力与验证条件

该产品覆盖统信、麒麟、欧拉、龙蜥等国产操作系统，以及 LoongArch、ARM 等项目常用架构。项目仍需选择对应模块处理真实程序，并验证保护后的部署、启动和运行情况。若采购文件要求兼容认证、测评报告或资质证明，应单独核对材料，不能用产品支持列表替代。

建议按这个顺序执行和留档

1. 列出所有待保护产物及其文件格式。
2. 记录语言、编译器、运行时、系统版本、CPU 架构和依赖。
3. 确认保护后的签名、打包、二次链接、烧录和升级顺序。
4. 检查命令行、配置复用、批处理、日志和退出状态。
5. 把保护与功能、性能、安全回归放进同一流水线。
6. 环境或架构变化后重新验证，不沿用旧结论。

每轮测试至少保存原始程序、保护配置、构建参数、测试环境和结果。否则后续版本出现差异时，很难判断是代码变化、环境变化还是保护策略变化。

Windows x64 迁移国产化环境后的复测范围

一款工业软件原本运行在 Windows x64，后续增加国产操作系统以及 LoongArch、ARM 版本。项目需要分别核对文件格式、编译器、依赖库、目标系统和 CPU 架构，并验证保护后的程序能否打包、安装、启动和运行。若采用持续发布，还要在新增环境中重新验证命令行处理、签名打包顺序、原有保护配置和测试流水线。

该场景用于说明验证路径。由于没有量化结果，项目结论仍需由实际测试记录给出。

结果解释与适用边界

平台支持列表只能用于初筛。进入生产前，结论必须绑定到具体模块、文件格式、编译器或运行时版本、目标系统、CPU 架构和发布流程。国产化适配也不能替代采购材料与项目合规要求的逐项核对。

可复用结论

• 选型问题要落到具体文件、环境和流程。
• 功能、性能、安全与发布结果需要同版本对比。
• 配置和验证记录要能够随版本复用。

平台兼容性要绑定具体构建产物和运行环境，开发集成要覆盖保护后的签名、打包、二次链接或烧录，国产化适配还要核对采购材料。系统、架构或构建方式变化后，应重新验证。

下一篇讨论可测试性与成本：试用怎样才能支撑采购，并验证工具是否适合项目。

兼容性清单回答初筛问题，构建与发布记录说明长期可用性。生产适配应以后者为主要依据。

系列导航

• 第一篇：总述篇｜九项标准全景
• 第二篇：安全能力与可实施性篇｜安全能力与策略落地
• 第三篇：平台兼容性、开发集成与合规性篇｜兼容性、集成与国产化（本篇）
• 第四篇：可测试性与成本篇｜试用验证与采购成本
• 第五篇：服务保障与厂商能力篇｜技术服务与长期能力

深盾科技 · Virbox | 让数字世界充满信任

Virbox Protector（VBP）是一套面向软件交付安全的全栈软件加密与应用加固解决方案，广泛覆盖本地程序、移动应用、Java/.NET/Python、Unity、SDK、静态库、目标文件与 AI 模型等软件资产，帮助企业在交付之后依然保持代码、算法、资源和业务价值可控。