.cpp的C ++文件中。我还将创建一个将使用相同的iOS应用AES密钥。是否可以将密钥保存在iOS中的C ++文件中？
反编译C ++文件并读取密钥有多困难？
这是Android的C ++文件：
#include <jni.h>
#include <string>
extern "C"
JNIEXPORT jstring JNICALL
Java_com_android_app_aesKeyFromJNI(JNIEnv *env, jobject /* this */) {
std::string secret = "somesecretkey";
return env->NewStringUTF(secret.c_str());
}
#1 楼
还不够努力！首先，如果将密钥另存为非加密字符串，则可以使用简单的
strings命令找到它，并且IDA x-ref甚至会显示反向器的使用位置。如果您将密钥保存为加密后，一个简单的断点将使他们看到解密后的密码。 （或了解解密算法）。
评论
“或了解解密算法”不应该理解与解密算法无关吗？至少在精心设计的加密中，我认为这是一种设计标准
– Hobbamok
18年11月8日在9:40
@Hobbamok我的观点是，如果您返回秘密，则需要对其解密。将写入解密的算法和密码。反向者可以简单地提取这些内容并解密原始秘密
–阿米拉格
18年11月8日在10:44
#2 楼
通过在十六进制编辑器（例如hte或查看器，例如xxd或od）中查看文件，或使用Sysinternals strings命令或在Linux / FreeBSD上使用strings(1)等，可以看到这样的纯文本字符串。大多数反向工程工具对字符串有单独的视图，因为它们通常对反向工程师特别有用。 Amirag已经为IDA指出了这一点。在Android方面，C ++文件很可能最终将成为ELF文件格式的共享对象。这些是具有已知结构的二进制文件。只需查看导出的功能/符号，就很容易找到“秘密”。即使您要进一步混淆，它仍然无济于事。混淆是通过混淆实现的安全。这不是真正的安全性。因此，即使将字符串写为某个异或字节数组或使用Caesar密码，如果达到此目的，也不会增加任何切实的保护。与用户。之所以将其称为机密是因为应将其保密。只是用编译器“破坏”这个秘密的表示就完全没有帮助。
如果这是用户不应该看到的秘密，它属于服务器端或属于HSM（硬件安全模块），但不以任何形式出现在用户的计算机上。没有其他方法可以调解对用户的不信任，并同时将“秘密”放到用户手中。这也是软件保护机制的根本难题。
评论
如果用户在记事本中打开文件，可以看到字符串吗？因为十岁的孩子会尝试的。
–罗宾
18年11月8日在7:12
@Robyn：从理论上讲，是的。但是，如果您指的是Windows记事本，则通常在Unix换行符方面存在很大的问题，此外，也无法确定二进制文件中到底有多少个换行符。因此，该文本可能会出现在长行中。就是说，如果您十岁的孩子知道要打开它，他们可以利用自动换行功能在某种程度上缓解该问题。
– 0xC0000022L♦
18年11月8日在8:16
评论
普通的ascii字符串绝不是秘密。是否有任何理由不使用为此目的而专门制造的Android密钥库系统？
无需反编译。有一块名为“字符串”的软件（通常已安装或可用于Linux和Mac OS的unixen），该软件将转储应用程序中的所有字符串。我要做的就是逐个测试字符串，直到找到正确的密钥为止。显然，我会跳过诸如“谢谢”之类的字符串。和“登录名：”
@slebetman下次我将输入我的密码“谢谢”。或“登录：”，它们将是安全的！
这种加密方法存在一些基本的安全问题，远远超出了从可执行文件中提取字符串的难度（无论如何混淆）。这几乎是非对称加密以及基于TLS的系统的确切目的。使用图书馆！可能会问到security.stackexchange.com