Android平台下能否加载加密.so库并在内存中实时解密使用？

这个方案的核心思路是通过APK签名绑定.so库的可用性，整体方向是可行的，但你最初设想的「用密钥加密.so，再用APK签名解密」其实不太好落地，反而你提到的CommonsWare给出的两个方向更具实操性，我来详细拆解下：

一、Java代码校验APK签名后加载.so #

• 实现逻辑：在Java层启动时，通过PackageManager获取当前APK的签名信息（比如提取签名的SHA-256哈希值），和你预先硬编码（最好做混淆处理）在代码里的合法签名哈希进行比对。
• 执行逻辑：只有签名校验通过，才调用System.loadLibrary()加载你的.so库；如果校验失败，直接跳过加载，让依赖.so的功能直接失效（比如弹出提示、返回错误状态）。
• 注意点：Java层的校验逻辑容易被逆向工具hook绕过，所以建议对这部分代码做深度混淆，或者把校验逻辑拆分成多个分散的片段，增加逆向难度。

二、.so库自身校验APK签名 #

• 实现逻辑：让.so库在初始化阶段（比如核心函数第一次被调用时），通过JNI调用Android系统API获取当前APK的签名信息，和内置在.so里的合法签名哈希做比对。
• 执行逻辑：如果签名不匹配，.so直接返回错误结果、终止核心逻辑执行，甚至可以主动崩溃（根据你的需求选择），这样依赖它的功能自然无法正常工作。
• 优势：.so的逆向难度比Java层更高，哪怕Java层的代码被篡改，只要.so本身没被破解，就能起到防护作用，安全性比第一种方案更强。

关于你最初加密解密思路的说明 #

你最初设想的「用密钥加密.so，借助APK签名解密」其实存在逻辑漏洞：APK的签名信息是公开可获取的——任何人拿到你的正版APK，都可以通过工具提取出签名哈希等信息。如果用这个公开信息来做解密密钥，那加密等于没有防护，别人很容易就能解密你的.so文件，起不到绑定签名的作用。

你提到的「无法完全抵御逆向工程，但聊胜于无」非常准确——这类方案本质是增加篡改成本，能有效挡住大部分非专业的篡改者（比如盗版打包、简单注入广告的人），但对于资深逆向工程师来说，还是有办法绕过，但确实比没有防护要强很多。

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