HarmonyOS鸿蒙Next中对于编译动态库,需要充分去除C/C++符号表并且混淆,有什么建议呢?
HarmonyOS鸿蒙Next中对于编译动态库,需要充分去除C/C++符号表并且混淆,有什么建议呢? 已经配置了strip,但是反编译看符号表还在;另外有什么低成本的混淆建议吗?
"nativeLib": {
"debugSymbol": {
"strip": true,
"exclude": []
}
}
你是否配置了-DCMAKE_BUILD_TYPE=Debug,在构建Release应用时,so文件是默认不包含符号表信息的,配置了DCMAKE_BUILD_TYPE属性会导致so文件包含符号表信息,
为了保护应用的代码,避免应用被恶意逆向分析,提高攻击者分析代码的难度,DevEcoStudio中默认提供了代码混淆能力,混淆后的JS、TS、ArkTS代码,不容易被逆向后读懂,混淆功能支持对名称进行混淆,包括对类、方法等做混淆处理。
代码混淆方案是基于源码混淆,将源码转为抽象语法树(AST),在AST上进行作用域分析和符号分析,混淆名称和属性,移除开发期间的日志打印代码,合并语句,压缩代码体积,在保证运行时性能无变化的前提下,有效保护HarmonyOS核心知识产权免受恶意逆向分析。
具体混淆效果如下例:
混淆前:
function getAgeInfo() {
function getAge() {
var age = 20;
return age;
}
var name = "jack";
if (name) {
return getAge();
} else {
return -1;
}
}
console.log(getAgeInfo());
混淆后:
function getAgeInfo() {
function a() {
var c = 0x14;
return c;
}
var b = 'jack';
if (b) {
return a();
} else {
return -0x1;
}
}
console['log'](getAgeInfo());
参考文档:https://gitee.com/openharmony/arkcompiler_ets_frontend/blob/master/arkguard/README-cn.md
混淆不支持c++,混淆支持JS、TS、ArkTS代码
更多关于HarmonyOS鸿蒙Next中对于编译动态库,需要充分去除C/C++符号表并且混淆,有什么建议呢?的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
在HarmonyOS鸿蒙Next中,编译动态库时去除C/C++符号表并进行混淆,可以通过以下步骤实现:
-
去除符号表:
- 使用
strip命令去除动态库中的符号表,减少文件大小并增强安全性。 - 示例命令:
strip --strip-all libexample.so。
- 使用
-
符号混淆:
- 使用LLVM的
obfuscator工具进行符号混淆,增加逆向工程的难度。 - 在编译时添加
-mllvm -fla -mllvm -sub -mllvm -bcf等选项进行控制流平坦化、指令替换和虚假控制流插入。
- 使用LLVM的
-
编译选项:
- 在编译动态库时,添加
-fvisibility=hidden选项,隐藏不需要暴露的符号。 - 使用
-fvisibility-inlines-hidden隐藏内联函数的符号。
- 在编译动态库时,添加
-
链接器脚本:
- 使用链接器脚本控制符号的可见性,确保只有必要的符号被导出。
-
代码混淆:
- 使用代码混淆工具对源代码进行混淆,增加代码的复杂性和可读性难度。
通过以上步骤,可以有效去除符号表并进行混淆,提升动态库的安全性。
在HarmonyOS鸿蒙Next中,编译动态库时去除C/C++符号表并进行混淆,可以采取以下措施:
-
去除符号表:使用编译器的
strip命令去除符号表,例如:strip --strip-debug libexample.so。这可以有效减少库文件的大小,并隐藏内部符号信息。 -
符号混淆:结合混淆工具(如Obfuscator-LLVM)对C/C++代码进行混淆处理,保护关键逻辑和函数名称不被轻易识别。
-
动态库保护:考虑使用动态库保护工具或方案,进一步增强动态库的安全性,防止逆向工程。
通过这些措施,可以显著提升动态库的安全性和隐私保护水平。

