Android安全：如何验证ProGuard/DexGuard对C++字符串常量的混淆效果

JADX只负责解析APK里的Java/Dex代码，对原生.so库无能为力，所以得用专门的二进制工具来分析。以下是具体操作步骤和针对不同混淆版本的验证要点：

第一步：提取APK中的.so文件 #

把APK后缀改成.zip解压，在lib/[目标架构]/目录下找到对应的.so文件（比如armeabi-v7a、arm64-v8a，取决于你的编译配置）。

第二步：用工具检查.so中的字符串 #

1. 快速查看可打印字符串 #

用系统自带的strings命令（Linux/macOS直接用，Windows可以用Git Bash或者GNU binutils）：

strings your-library.so

如果密钥没被混淆，输出里会直接显示明文；如果混淆生效，你看不到明文密钥——要么是一堆乱码，要么根本找不到相关字符串（如果是编译时加密或运行时动态生成的话）。

2. 深入反汇编分析 #

如果想确认底层逻辑，用objdump反汇编：

objdump -d your-library.so

查找代码中引用字符串的位置：未混淆的话，会看到指向字符串常量池的指令和明文；混淆后的代码要么看不到明文，要么是加密后的字节序列，或者是调用解密函数的逻辑。

也可以用免费开源的Ghidra或者商业工具IDA Pro，它们能可视化分析.so的段结构（比如存储只读字符串的.rodata段），直接查看该段是否存在明文密钥。

第三步：针对不同混淆版本的验证逻辑 #

• 未使用混淆工具的Debug/Release版：strings命令应该能直接输出明文密钥，这是正常情况，因为没有做任何混淆处理。
• 仅启用ProGuard的版本：ProGuard只混淆Java代码，对C原生字符串没有作用，所以.so里的密钥还是明文——除非你在C编译阶段单独加了自定义加密或编译器优化。
• 启用DexGuard+ProGuard的版本：DexGuard支持原生代码的字符串加密/混淆，此时strings查不到明文密钥，反汇编后只能看到加密后的内容或动态解密逻辑，这就说明混淆生效了。

额外验证手段 #

• 动态调试：用Android Studio的Native Debugger或者gdb attach到运行中的APP进程，在JNI调用密钥的代码处下断点，查看内存中的值。如果混淆生效，内存里的密钥是运行时临时解密的，而非.so中直接存储的明文。
• 检查编译配置：确认C++编译脚本或DexGuard配置里是否开启了原生字符串混淆选项，或者是否自己实现了密钥加密逻辑（比如把密钥存在字节数组，运行时再转成字符串）。

内容的提问来源于stack exchange，提问作者Bitwise DEVS