1. 项目概述从“硬”到“软”的加密思维跃迁在软件开发的江湖里数据安全始终是悬在开发者头顶的达摩克利斯之剑。我们习惯了依赖硬件加密狗、安全芯片这类“硬”家伙来保护核心资产它们就像给软件上了一把物理锁钥匙握在自己手里。但这些年随着云原生、微服务、SaaS化的浪潮软件的分发和部署形态发生了翻天覆地的变化。一个需要下载安装包、插上U盾才能运行的软件在追求极致用户体验和快速迭代的今天显得越来越笨重和不便。于是“软加密”这个概念被重新推到了台前。所谓“软加密”顾名思义就是不依赖特定硬件完全通过软件算法、逻辑和运行时环境来保护软件授权、核心代码或敏感数据的一种技术思路。它听起来似乎不如硬件加密牢靠毕竟软件是运行在用户可控的环境里。但恰恰是这种“不牢靠”的错觉让很多人低估了精心设计的软加密方案的威力。一个好的软加密方案其核心目标并非制造一个“无法破解”的绝对壁垒——这在理论上几乎不可能——而是将破解的成本和难度提升到远超软件本身价值的高度同时为合法用户提供无缝的体验。它是一场攻防双方在逆向工程、代码混淆、运行时自校验、环境指纹识别等多个维度上的智力博弈。我接触过不少项目从传统的桌面软件授权到如今基于订阅制的SaaS服务后端API保护再到移动端App的核心逻辑防护软加密的思路无处不在。这次我就结合自己踩过的坑和总结的经验系统性地整理一下软加密的设计思路与实现路径。无论你是在保护一个算法库、一个游戏的核心逻辑还是一个商业软件的生产许可希望这些内容能给你带来一些切实的参考。2. 软加密的核心设计思路与目标拆解在动手写一行代码之前我们必须想清楚软加密到底要防什么要达到什么效果很多项目一开始方向就偏了追求“绝对安全”投入大量资源做高强度混淆结果用户体验极差维护成本巨高最后发现破解者绕过了所有防御直接修改了一个内存值就搞定了。所以明确设计目标是第一步。2.1 防御目标的层次化定义软加密的防御不是铁板一块而应该是一个分层的、动态的体系。我们可以将其分为几个层次第一层防君子不防小人。这一层主要针对普通的、没有逆向工程能力的用户。目标是防止通过简单的静态分析如字符串搜索、配置文件修改或简单的运行时调试如Cheat Engine修改内存就能完成的破解。例如软件是否将授权码“123456”明文写在配置文件里核心功能判断是否只是一个简单的if (isRegistered)这一层的实现成本最低但能过滤掉绝大部分“顺手”的破解尝试。第二层增加专业破解者的分析成本。当破解者具备一定的逆向工程能力会使用IDA Pro、Ghidra、OllyDbg等工具时我们的目标就变成了让他们的分析过程变得极其痛苦和耗时。这包括但不限于代码混淆控制流扁平化、指令替换、字符串加密、反调试、反模拟器检测等。这一层的核心思想是“拖延时间”让破解者每分析一个关键函数都要花费数小时甚至数天大大降低其破解的投入产出比。第三层防止自动化破解和批量盗版。高价值的软件可能会吸引团队制作通用的“破解补丁”或“注册机”。这时我们需要引入设备指纹、环境绑定、在线激活与校验等机制。目标是让每一个破解都必须是“定制化”的无法通过一个通用的工具批量完成。例如将授权信息与用户的硬盘序列号、主板信息、网卡MAC地址需注意隐私等绑定即使破解者分享了授权文件在其他机器上也无效。第四层核心逻辑的动态保护与自毁。对于最核心的算法或业务逻辑可以采用动态代码生成、白盒加密、虚拟机保护VMP等技术。这些技术将核心代码转化为一种中间表示或加密形态仅在运行时动态解密和执行并且代码与数据高度融合使得静态反编译几乎无法还原原始逻辑。这是成本最高、对性能影响最大的一层通常只用于保护最关键的一小部分代码。一个健壮的软加密方案通常会融合以上多个层次形成纵深防御。但具体到你的项目需要根据软件的价值、预期的破解威胁等级、以及对性能损耗和用户体验的容忍度来权衡选择合适的技术组合。记住没有完美的方案只有权衡下的最优解。2.2 关键设计原则安全性与可用性的平衡在设计过程中以下几个原则需要时刻牢记透明化原则对合法用户对于已经授权或正常使用的用户加密机制应该尽可能透明不增加额外的操作步骤不影响软件的性能和稳定性。理想状态是用户完全感知不到加密的存在。失效安全原则当加密校验失败或被破坏时软件的行为应该是可预测和可控的。是优雅降级部分功能受限还是直接退出绝不能因为加密模块自身的Bug导致合法用户无法使用。通常我们会设计一个“安全状态机”在检测到篡改时不是立刻崩溃而是可能引入随机错误、降低性能、或延迟触发失效让破解行为难以被简单测试验证。去中心化与混淆原则不要把所有的校验逻辑都放在一个checkLicense()函数里。应该将校验逻辑打散融入到正常的业务代码流中。例如在软件启动时校验一次在某个核心功能执行前再校验一次在保存文件时又用另一个逻辑校验一次。这些校验点彼此关联形成一个网状结构让破解者难以通过定位并修改一个点就完成破解。环境感知原则软件应该有能力感知自己所处的运行环境是否“正常”。这包括检测调试器、虚拟机、常见的破解工具进程以及检查自身的关键代码段是否被修改完整性校验。环境感知的结果可以作为授权校验的一个动态输入因子。可更新与可演进原则加密方案不是一劳永逸的。一旦发现被破解应该有能力通过在线更新如替换关键的校验逻辑模块、更新加密密钥来修复漏洞至少能为下一个版本积累经验。这意味着加密方案需要一定的可配置性和可更新性。3. 核心技术点解析与方案选型明确了目标和原则我们就可以来看看具体有哪些技术武器可以用于构建软加密体系。我会从基础到高级逐一分析其原理、实现要点和适用场景。3.1 基础加固代码混淆与反调试这是软加密的“基本功”目的是增加静态和动态分析的难度。代码混淆名称混淆将类、方法、变量名替换为无意义的短字符串如a, b, c1。这能有效防止通过名称猜测功能。Java的ProGuard .NET的Obfuscator JavaScript的UglifyJS都擅长于此。控制流混淆这是混淆的核心。通过插入无效代码花指令、改变代码执行流如将顺序执行的if-else改为switch加goto、或者使用“控制流扁平化”技术将所有的基本块放到一个大的switch或while循环里通过一个状态变量来跳转使得反编译后的代码逻辑极其晦涩难懂。字符串加密程序中的提示信息、API密钥、加密常量等字符串是重要的突破口。在编译前或编译后将这些字符串加密存储在运行时动态解密使用。这样在静态分析时逆向者看不到明文字符串。指令替换用一系列等价的、但更复杂的指令序列来替换简单的指令。例如将x y 1替换为x y - (-1)或更复杂的位操作。实操心得混淆不是越强越好。过度的控制流混淆会显著影响运行时性能可能达到10%-30%的损耗并可能引发一些编译器优化相关的诡异Bug。我的经验是对性能敏感的核心循环代码谨慎使用高强度混淆而对于授权校验、密钥处理等不常执行的逻辑则可以施加最强的混淆。反调试与反分析时间差检测在关键代码路径前后记录时间戳。如果代码在调试器单步执行下运行时间差会异常大。调试器进程检测检查系统中是否存在已知的调试器进程如ollydbg.exe, x64dbg.exe, idaq.exe, gdb等。在Windows上可以通过CreateToolhelp32Snapshot枚举进程在Linux上可以检查/proc/self/status中的TracerPid字段。断点检测检查关键函数入口是否被设置了软件断点INT 3指令即0xCC。可以遍历函数代码搜索0xCC字节。硬件断点与内存访问检测利用SEH结构化异常处理或VEH向量化异常处理来捕获调试器设置硬件断点或内存访问断点触发的异常。虚拟机/模拟器检测针对那些在虚拟机中进行分析的破解者。可以通过检测特定的硬件信息如特定的网卡型号、显卡型号、CPU指令如CPUID指令返回的厂商信息、或一些虚拟环境特有的行为如执行某些特权指令的耗时来判断。3.2 授权与绑定机制设计这是软加密的业务核心决定了授权如何生成、分发和校验。1. 离线授权文件模式这是最传统的模式。用户购买后获得一个授权文件License File。生成授权服务器根据用户提供的设备指纹如硬盘序列号、主板UUID的哈希值和产品信息使用私钥进行签名生成一个包含授权信息到期时间、功能模块等和签名的文件。校验软件启动时读取本机设备指纹与授权文件中的信息进行比对并使用内置的公钥验证签名。只有设备匹配且签名有效授权才成立。优点完全离线适用于无网络环境。缺点一旦私钥泄露可以伪造任意授权文件授权文件与设备绑定用户更换硬件后需要重新授权。2. 在线激活与心跳校验模式这是目前更主流和安全的模式尤其适合SaaS或需要持续服务的软件。激活用户输入购买获得的激活码或账户密码。软件将激活码和本机设备指纹发送到授权服务器。服务器校验激活码有效后在数据库记录“设备A已使用激活码B”并生成一个有时效性的令牌Token返回给客户端。客户端软件保存此令牌。心跳校验软件在运行期间定期如每24小时或在执行关键操作前向授权服务器发送心跳携带令牌和设备指纹。服务器验证令牌有效性、设备是否匹配、授权是否过期或被吊销。验证通过则返回成功否则返回错误码引导用户重新授权或提示失效。优点服务器端有完全控制权可以随时吊销某个授权可以轻松实现订阅制到期自动失效一份授权可以在多设备登录取决于策略用户体验好。缺点必须依赖网络服务器需要承担校验压力需要设计好离线容忍策略例如令牌在有效期内允许离线运行一段时间。3. 密钥与算法保护无论哪种模式加解密、签名的密钥和算法都是重中之重。白盒加密在可能被逆向的环境下标准的AES、RSA算法及其密钥是脆弱的。白盒加密技术将密钥与算法融合生成一个庞大的查找表使得在内存中提取密钥变得极其困难。通常用于保护一个用来解密其他关键数据或代码的“主密钥”。密钥分割与动态合成不要将完整的密钥硬编码在代码中。可以将密钥分割成多个片段分别隐藏在代码的不同位置如作为常量数组、隐藏在字符串中、甚至通过某些计算动态生成。在需要使用时再将这些片段动态组合起来。同时密钥本身也可以被另一个密钥加密存储。使用平台提供的安全存储利用操作系统提供的安全设施如Windows的DPAPI数据保护API、macOS的Keychain、iOS的Keychain Services、Android的Keystore系统。这些设施能将密钥存储在硬件安全区域如TEE或由系统主密钥保护比应用自身存储安全得多。3.3 完整性校验与防篡改软件需要确保自身在运行前和运行中没有被修改。文件完整性校验数字签名这是最基本的一环。在发布软件时对核心可执行文件或动态库进行数字签名使用代码签名证书。操作系统在加载时会验证签名。我们自己在软件启动时也可以再次计算核心文件的哈希值如SHA-256与预置的或从服务器获取的正确哈希值比对。内存代码段校验破解者可能通过补丁工具直接修改内存中的指令。我们可以在运行时对关键函数的内存区域计算校验和。例如在函数开头和结尾插入一段校验代码该代码计算函数体不包括校验代码自身的哈希值与一个常量比较。如果被修改哈希值就会变化。相互校验与网状结构这是提升破解难度的有效手段。让模块A校验模块B的完整性同时模块B又校验模块A的某个关键数据区。形成一种相互依赖、相互保护的网状结构。破解者修改一处可能会引发另一处的校验失败导致程序行为异常而非简单的功能解锁。4. 一个综合性的软加密实现方案设计下面我将以一个虚构的、需要较高安全等级的桌面数据分析软件“DataInsight Pro”为例勾勒一个综合性的软加密实现方案。该软件采用离线授权文件在线心跳校验的混合模式。4.1 系统架构与组件设计整个加密授权系统分为三部分客户端SDK嵌入在DataInsight Pro中负责设备指纹采集、本地授权文件解析与校验、心跳通信、运行时反调试/反篡改检测。授权管理后台Web服务供软件开发商管理授权、生成激活码、查看设备绑定情况、处理吊销请求。授权校验服务器API服务高可用、无状态的微服务集群专门处理客户端的激活和心跳请求进行快速校验并返回结果。核心流程如下用户安装软件后首次启动提示输入激活码。客户端SDK采集设备指纹综合CPU ID、主板序列号、主硬盘序列号的哈希连同激活码调用激活API。授权校验服务器验证激活码有效性是否已使用、是否在有效期。如果有效则在数据库记录(激活码 设备指纹哈希 状态)并生成一个长期有效的Refresh Token和一个短期有效的Access Token例如Access Token有效期7天Refresh Token有效期1年返回给客户端。客户端将Refresh Token和Access Token及其过期时间加密后存入本地安全存储如使用DPAPI保护的文件或系统钥匙串。此后软件每次启动或定时如每12小时客户端使用Access Token进行心跳校验。如果Access Token过期则自动使用Refresh Token向服务器申请新的Access Token。服务器在校验心跳时除了检查Token还会核对设备指纹是否与绑定记录一致并检查授权状态是否被管理员吊销。客户端SDK在软件运行期间会不定时地在多个业务逻辑点如打开大型文件、执行高级分析时插入轻量级的授权状态检查检查内存中的标志位并运行反调试检测。4.2 客户端SDK关键实现细节1. 设备指纹生成目标是生成一个足够稳定同一设备多次获取一致、唯一性高、且相对难以伪造的指纹。// 伪代码示例Windows平台下综合指纹生成 std::string GenerateDeviceFingerprint() { std::string fingerprint; // 1. 获取CPU ID (使用CPUID指令) fingerprint GetCPUIDHash(); // 2. 获取主板序列号 (通过WMI查询Win32_BaseBoard) fingerprint GetBaseBoardSerialHash(); // 3. 获取主硬盘序列号 (通过DeviceIoControl获取) fingerprint GetPhysicalDrive0SerialHash(); // 4. 获取网卡MAC地址可选注意隐私和虚拟网卡问题 // fingerprint GetPrimaryMACHash(); // 5. 对拼接后的字符串进行二次哈希如SHA-256并取部分字节进行Base64编码 return ComputeSHA256Base64(fingerprint); }注意事项硬盘序列号在某些虚拟化环境下可能为空或相同网卡MAC地址用户可修改且涉及隐私需谨慎使用。最佳实践是综合多项信息即使其中一两项失效或变更只要核心项如CPU主板未变仍可识别为同一设备。同时应对采集的信息进行哈希处理不要传输或存储原始敏感信息。2. 本地安全存储使用平台提供的安全API而不是自己写文件加密。Windows使用CryptProtectData和CryptUnprotectData函数DPAPI。数据由当前用户的登录凭证保护。macOS/iOS使用Keychain Services。Linux可以考虑使用libsecret或通过Gnome Keyring、KWallet等桌面环境提供的服务但一致性较差。退而求其次可以使用一个由用户输入密码派生的密钥来加密存储文件。3. 令牌管理与心跳机制# 伪代码示例客户端令牌管理与心跳 class LicenseClient: def __init__(self): self.access_token None self.refresh_token None self.token_expiry None self.device_fp generate_device_fingerprint() self.local_license_file license.dat # 实际使用DPAPI保护 def activate(self, activation_code): # 调用服务器激活API resp requests.post(ACTIVATE_URL, json{code: activation_code, device_fp: self.device_fp}) if resp.ok: data resp.json() self.access_token data[access_token] self.refresh_token data[refresh_token] self.token_expiry time.time() data[expires_in] self._save_tokens_securely() # 保存到安全存储 return True return False def heartbeat(self): if not self.access_token or time.time() self.token_expiry - 300: # 过期前5分钟刷新 if not self._refresh_access_token(): return False # 刷新失败需要重新激活 # 正常心跳 resp requests.post(HEARTBEAT_URL, headers{Authorization: fBearer {self.access_token}}, json{device_fp: self.device_fp}) if resp.status_code 401: # Token无效 return self._refresh_access_token() # 尝试刷新 return resp.ok def _refresh_access_token(self): # 使用Refresh Token获取新的Access Token if not self.refresh_token: return False resp requests.post(REFRESH_URL, json{refresh_token: self.refresh_token}) if resp.ok: # 更新token和过期时间 self._save_tokens_securely() return True return False # 刷新失败Refresh Token可能也失效了4. 代码内嵌校验点不要只在启动时校验。将授权状态与业务逻辑深度绑定。// 伪代码示例在业务逻辑中嵌入校验 public class AdvancedAnalysisEngine { private LicenseManager licenseManager; public ComplexResult performAdvancedAnalysis(DataSet data) { // 校验点1进入高级分析前 if (!licenseManager.checkFeature(advanced_analysis)) { throw new LicenseException(高级分析功能未授权); } // ... 部分计算逻辑 ... // 校验点2在某个关键计算步骤中间 licenseManager.doLightweightCheck(); // 内部可能检查内存标志或调用一个被混淆的校验函数 // ... 更多计算逻辑 ... // 校验点3准备输出结果前再次校验 if (licenseManager.isTrial() data.size() TRIAL_LIMIT) { throw new LicenseException(试用版数据量超限); } return generateResult(); } }这些checkFeature、doLightweightCheck函数内部实现应该是被高度混淆和分散的。4.3 服务端关键设计1. 授权数据模型-- 简化版数据表设计 CREATE TABLE licenses ( id BIGINT PRIMARY KEY, activation_code VARCHAR(64) UNIQUE NOT NULL, -- 激活码 product_id VARCHAR(32) NOT NULL, max_activations INT DEFAULT 1, -- 允许激活的设备数 valid_from DATETIME, valid_until DATETIME, -- 订阅到期时间 is_revoked BOOLEAN DEFAULT FALSE, created_at DATETIME ); CREATE TABLE activations ( id BIGINT PRIMARY KEY, license_id BIGINT FOREIGN KEY REFERENCES licenses(id), device_fingerprint_hash VARCHAR(128) NOT NULL, -- 设备指纹哈希 last_heartbeat DATETIME, status ENUM(active, inactive, suspicious), UNIQUE KEY unique_activation (license_id, device_fingerprint_hash) -- 防止同一设备重复激活 ); CREATE TABLE auth_tokens ( id BIGINT PRIMARY KEY, activation_id BIGINT FOREIGN KEY REFERENCES activations(id), refresh_token_hash VARCHAR(256) NOT NULL, -- 存储哈希值而非明文 access_token_hash VARCHAR(256), expires_at DATETIME, created_at DATETIME );2. 激活与心跳API逻辑激活检查激活码是否存在、未吊销、在有效期内、激活次数未超限。然后创建激活记录生成Token。Token建议使用JWT格式包含激活ID、设备指纹哈希前几位、过期时间并用服务端私钥签名。心跳解析Token验证签名和过期时间。根据Token中的激活ID查询数据库核对设备指纹哈希是否匹配并检查对应的授权是否被吊销。更新last_heartbeat时间。如果发现一个激活码在极短时间内从两个差异巨大的设备指纹发起心跳例如不同国家IP可以标记为suspicious供后台审查。5. 常见问题、对抗策略与调试技巧即使设计了严密的方案在实际对抗中依然会遇到各种问题。下面是一些常见场景和应对思路。5.1 典型攻击手段与防御加固攻击手段描述防御加固思路静态分析破解使用反编译工具直接查看源代码定位关键判断函数如checkLicense。1.高强度代码混淆控制流扁平化、字符串加密。2.将校验逻辑分散到数十个甚至上百个函数中相互调用。3.关键算法使用原生库C/C编写编译成.so/.dll增加逆向难度。动态调试与内存修改使用调试器运行程序在内存中修改授权标志位如将isRegistered从false改为true。1.反调试技术进程检测、时间差、断点检测。2.多线程交叉校验在一个隐蔽的线程里定期检查主线程中的关键内存数据是否被篡改。3.使用非易失的标志位授权状态不仅存在于内存变量还和某些复杂的、全局的计算结果绑定例如某个全局哈希值必须等于由设备指纹和当前日期计算出的某个值。补丁与文件修改直接修改可执行文件跳转JMP或覆盖NOP掉校验失败的代码分支。1.文件数字签名与完整性校验启动时校验自身。2.代码自校验关键函数计算自身的CRC或哈希与嵌入在别处的正确值对比。3.加壳/虚拟机保护使用商业保护壳如VMProtect, Themida或开源加壳工具对核心代码段进行加密和虚拟化使原始指令在运行时才被还原极大增加静态分析和直接打补丁的难度。网络协议分析抓包分析客户端与授权服务器的通信尝试模拟或重放请求。1.使用HTTPS防止明文通信。2.请求签名每个请求包含时间戳和随机数并用客户端存储的密钥对请求体进行签名服务器验证签名以防止重放攻击。3.关键数据加密即使使用HTTPS激活码、设备指纹等敏感信息在客户端发送前也应先进行非对称加密使用服务器公钥。模拟合法环境破解者分析出设备指纹的生成算法尝试伪造或固定一个指纹使所有机器都用同一个“合法”指纹。1.指纹算法混淆与动态化指纹生成算法本身被混淆且可能加入一些动态因子如当前日期、运行进程列表的哈希等使得每次生成的指纹都有细微变化但服务器端可以通过一个容忍度算法来匹配。2.多因子绑定除了硬件指纹还可以绑定用户账户在线模式。3.服务器端行为分析同一个指纹从全球不同IP频繁激活或心跳是不合常理的服务器可以标记并限制。5.2 开发与调试阶段的实用技巧在开发软加密功能时调试本身会变得困难因为反调试技术可能会“敌我不分”。以下是一些技巧设计调试开关在编译时通过宏定义如#DEBUG_SOFTGUARD来控制是否启用强混淆和反调试。在开发版本中关闭这些功能方便调试。日志分级输出实现一个详细的、分级的日志系统如TRACE, DEBUG, INFO, ERROR。在调试版本中输出TRACE级别信息记录加密校验的每一步在发布版本中只保留ERROR级别日志并且日志内容本身可以加密或混淆。模拟服务器开发一个本地的、模拟授权服务器的Mock服务可以随意返回成功、失败、过期等各种状态用于测试客户端的各种处理流程。单元测试与集成测试为加密授权模块编写充分的单元测试模拟各种正常和异常输入。同时要有完整的集成测试流程测试从激活、心跳到功能校验的完整链条。性能 profiling在启用所有混淆和保护后务必进行性能测试Profiling评估对软件启动时间、关键操作响应时间的影响确保在可接受范围内。5.3 上线后的监控与响应软加密是一场持续的战斗。上线后需要密切关注监控异常激活模式在授权服务器后台监控短时间内同一激活码来自大量不同设备指纹的请求或者大量心跳失败、Token刷新的请求。这可能是破解尝试或密钥泄露的迹象。建立漏洞反馈渠道鼓励用户特别是企业用户通过正规渠道反馈问题。有时用户环境中的某些安全软件或特殊配置可能会误触发你的反调试或完整性校验导致合法用户无法使用。快速响应这些反馈可以避免误伤。准备应急响应方案一旦发现确凿的破解版本在流传应有预案。例如通过心跳机制向所有客户端推送一个紧急更新更新一部分校验逻辑或密钥或者在服务器端将涉及泄露的激活码或设备指纹列入黑名单。持续迭代定期如每个大版本更新加密方案更换混淆策略甚至更换核心的加密算法和密钥。让破解者之前的工作成果失效。6. 总结与个人体会软加密的设计与实现本质上是在用户体验、开发成本、运行性能和安全性之间寻找一个精妙的平衡点。它没有银弹任何一个单一技术都可能被绕过。因此纵深防御和提高攻击成本是核心思想。从我个人的经验来看有几点体会特别深刻第一安全是一个过程而不是一个产品。不要指望设计一个方案就能一劳永逸。你需要把它当作一个需要持续维护和更新的核心模块关注安全社区的动态了解新的攻击手法并适时调整你的策略。第二过度安全是另一种不安全。我曾经在一个项目中使用了一个非常激进的反调试方案导致软件在某些企业的虚拟桌面环境下频繁崩溃因为那些环境使用了我们未预料到的调试或监控技术。这造成了严重的客户投诉。后来我们引入了更温和的检测和优雅降级机制问题才得以解决。用户体验的底线必须守住。第三测试测试再测试。软加密代码的测试非常棘手。你需要测试正常流程更需要测试各种异常和对抗场景网络断开时、系统时间被篡改时、调试器存在时、关键文件被修改时……构建一个完整的测试矩阵至关重要。第四理解你的对手。抽时间自己尝试用IDA Pro或Ghidra打开自己的软件去掉强保护看看从逆向者的视角你的代码是什么样子的。这会让你对哪些地方是薄弱环节有最直观的认识。最后对于大多数商业软件来说一个实现了上述多层次防御的软加密方案已经足以阻挡99%的破解尝试并将剩下1%的专业破解者的成本提高到非常高的水平。与此同时它能保障99.9%的合法用户顺畅使用。这或许就是一个成功的软加密方案应该达成的目标。
