北京
跨平台应用开发框架Codename One本周发布App Hardening功能，将代码混淆与加固统一到云端构建流程中，在应用拆分为Android、iOS、JavaScript、Windows、Linux和桌面版本之前，对合并后的应用JAR执行一次完整的安全转换。
这一设计思路与常见的"只加固Android产物"做法形成对比。Codename One团队在发布说明中指出，仅对单一平台产物做混淆，对跨平台应用而言是一种薄弱的安全模型。App Hardening的目标设定在DexGuard级别的抵抗能力：重命名有意义的符号、在目标平台允许时移除明文应用字符串、扭曲选定的控制流，同时保持崩溃报告可读。
安全决策统一化
团队明确表示，这并非声称逆向工程变得不可能，而是承诺让同一个安全决策覆盖整个应用，而不是让每个平台各自使用不同的工具和配置。加固引擎在云端构建服务内运行，作用于合并后的应用JAR。这一位置安排有其用意：引擎在ParparVM将字节码转换为C语言之前、在R8处理Android之前、在JavaScript或原生桌面后端消费程序之前，就能看到应用类和捆绑的库。
本次发布包含多项内容：开源引擎、retrace支持、客户端API、构建预检、崩溃载荷变更和文档（PR #5527），以及将引擎接入云端构建器并在服务器端强制执行企业版授权的BuildDaemon PR #173。
服务器端授权门禁
服务器端的门禁是有意设计的。非企业版构建若请求加固，会收到失败说明，而不会返回一个看起来已受保护但实际未处理的普通二进制文件。对大多数项目而言，唯一需要的设置是：
codename1.arg.harden.level=standard加固级别是累积式的。开发者可以用harden.rename、harden.strings和harden.controlFlow覆盖单个转换，也可以用harden..enabled=false提示将某个目标平台排除在外。未知的级别会导致构建失败，而不是静默关闭。
Keep规则与反射处理
按名称解析的类需要keep规则，例如：
codename1.arg.harden.keep=-keep class com.example.payment.NativeGateway { *; }引擎本身已保留应用入口点、生成的引导代码和原生接口对等体。Codename One不使用运行时反射来解析普通应用类，这消除了大量keep规则猜测工作。不过，如果第三方库加载包相对路径的资源，仍可能需要显式规则，因为包名改变而资源路径不变。
如果对所有平台应用所有转换，会产生更大的二进制文件，却不会增加保护，甚至可能破坏某个后端优化器。App Hardening使用单一策略，但会调整具体机制：重命名字典使用zq前缀，而非常见的a、b、c短名。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
