1. 目标给openharmony 6.1 release代码生成一个 JSON 文件为了精准抓取鸿蒙每个源码文件的编译参数与架构上下文从而让你的自定义 Clang 脚本能够无需实际编译就能高效、精准地进行离线批量漏洞扫描。2.具体实现2.1. 确定芯片架构具体操作这里是在我拉取好的源码目录下执行的其中rk3568是我选择的芯片类型对应的是arm架构./build.sh --product-name rk3568 --gn-args is_debugtrue --gn-flags--export-compile-commands这一步完成之后会出现/openharmony_6.1/out/rk3568/build.ninja文件原理Clang AST抽象语法树并不是纯粹的文本解析它是带有语义和目标平台属性的。如果直接脱离芯片架构直接去用默认的 x86_64 去解析鸿蒙代码会引发以下灾难1. 核心类型大小Sizeof会完全错乱致命在 C/C 中指针、基础数据类型的大小和内存对齐Alignment是强依赖芯片架构的数据类型差异例如long类型在 32 位 ARM 架构上通常是 4 字节而在你的 64 位 x86 电脑上是 8 字节。指针与结构体偏移当 Clang AST 计算结构体中指针的偏移量Offset时如果架构选错算出来的内存布局就是错的。这会导致你的指针越界检出算法、空指针分析直接报出大量虚假的错误误报或者真正的数据溢出漏洞根本检测不到漏报。2. 条件编译条件错乱AST 节点大面积缺失鸿蒙的底层源码中充斥着大量的平台宏隔离#ifdef __arm__ // ARM 架构特有的安全指针处理逻辑你想检测的代码 void* ptr get_arm_secure_buffer(); #elif defined(__x86_64__) // x86 架构的逻辑 void* ptr get_x86_buffer(); #endif如果你不指定对应的芯片架构Clang 在构建 AST 时会默认走__x86_64__分支导致真正的鸿蒙 ARM 代码直接被预处理器砍掉后续进行clang ast分析连代码节点的面都见不到。2.2 逆向导出只包含 C/C 的 compile_commands.json./prebuilts/build-tools/linux-x86/bin/ninja -w dupbuildwarn -C ./out/rk3568 -t compdb cxx c ./out/rk3568/compile_commands.json这一步完成之后会出现/openharmony_6.1/out/rk3568/compile_commands.json文件大小约为2.3G2.3 常见问题在2.1结束之后我有一个报错打开error.log(在/openharmony_6.1/out/rk3568/目录下)发现是N 在解析//third_party/libnl/BUILD.gn第 13 行时调用了一个外部脚本install.sh。这个脚本返回了1非零退出码导致整个构建流程在“画图纸”阶段就报错退出了。解决方法是修复libnl的环境依赖sudo apt-get update sudo apt-get install unzip tar patch pkg-config然后就可以顺利执行2.2了
