Android NDK/JNI存储密钥两种实现方式的安全性对比

Android NDK开发中，把密钥写在cpp方法内部、或者抽到头文件引入这两种方案，安全强度完全没有区别，二者面对反编译、逆向破解时的防护能力是一样的，不存在某一种有额外安全弱点的情况。

两种方案的实现参考 #

方法1：密钥直接写在lib.cpp方法内 #

lib.cpp代码：

extern "C"
JNIEXPORT jstring JNICALL
Java_com_app_keytest_KeyHelper_getKey(JNIEnv *env, jobject) {
    std::string API_KEY = "YOUR_API_KEY";
    return env->NewStringUTF(API_KEY.c_str());
}

方法2：密钥抽离到独立keys.h头文件引入 #

keys.h代码：

std::string API_KEY = "YOUR_API_KEY";

lib.cpp代码：

#include "keys.h"

extern "C"
JNIEXPORT jstring JNICALL
Java_com_app_keytest_KeyHelper_getKey(JNIEnv *env, jobject) {
    return env->NewStringUTF(API_KEY.c_str());
}

安全性一致的核心原因 #

C/C++的#include是预编译阶段的纯文本替换逻辑，源码层面的文件拆分不会对最终编译出的二进制文件产生本质影响：两种写法编译后，明文字符串YOUR_API_KEY都会被直接存到.so文件的常量数据段中。
逆向人员破解时拿到的是打包好的APK和内部的so文件，根本看不到你源码是分了几个文件写的，不管你用哪种写法，只要用strings命令扫描so文件，或者用IDA、Ghidra等逆向工具加载so查看常量区，几秒钟就能提取到明文密钥，破解难度没有任何差异。

注：方法2的写法存在一个编译层面的问题：如果keys.h被多个cpp文件同时引入，会触发全局变量重复定义的编译报错，但这属于编码规范问题，和安全性无关。

补充说明 #

这两种方案本质都是Native层明文硬编码密钥，只能防住只会反编译Java/Kotlin代码、完全不了解Native逆向的新手，对有基础逆向能力的攻击者来说防护效果几乎为0。如果真要保护敏感密钥，优先把密钥相关的校验、签名逻辑放在服务端实现，不要在客户端存储明文密钥；如果业务必须把密钥放在客户端，至少要做字符串混淆、运行时动态计算拼接，不要直接把明文作为常量写在代码里。

内容的提问来源于stack exchange，提问作者Ajantha Wijerathna