6

我是一个初学者的java程序员。我正在开发一个解密一些数据的应用程序。解密密钥被硬编码到软件中，因此可以通过分析字节码来查看。

我知道不能完全防止逆向工程，所以我想做的就是让这个过程尽可能地困难。

我的想法不是直接将密钥放入我的代码中，而是让它经过某种转换。例如，我可以写 -

private static final byte[] HC256A = Hex
            .decode("8589075b0df3f6d82fc0c5425179b6a6"
                    + "3465f053f2891f808b24744e18480b72"
                    + "ec2792cdbf4dcfeb7769bf8dfa14aee4"
                    + "7b4c50e8eaf3a9c8f506016c81697e32");

这样，查看字节码的人就无法立即读取它。但是必须遵循逻辑并对其应用转换，这在字节级别不会那么容易。

那你们怎么看？这有用吗？除了十六进制解码之外，最好的转换是什么？是否有任何其他方法可用于保护硬编码的解密密钥？

感谢您的所有建议。

4

3 回答 3

8

攻击这种混淆（尤其是在字节码语言中）的正确方法是将调试器附加到传递密钥的位置（如果无法调试，则从该位置开始分析代码）。这样，攻击者根本不需要寻找密钥，也不关心密钥的混淆程度。所以你需要重新考虑你的设计。

如果您只想保护业余潜伏者，那么拆分密钥并对它的各个部分进行异或（可能使用不同的密钥）就足够了。还有一个技巧 - 从代码中已经存在的文本常量（例如应用程序名称）中派生密钥。这使得密钥不如拆分或 XORing 明显。

于 2011-05-20T09:37:22.453 回答
3

根本不要将密钥编码到源代码中。将其分开，单独发送，例如在 Java 密钥库中，并且只发给您信任的客户/站点/客户，并在许可证中添加一些法律术语，如果他们泄露了密钥库，则由他们承担责任。

于 2011-05-20T09:53:57.127 回答
0

面对类似的问题（在 c 中），我使用了一次性 XOR 垫。这很好，因为它看起来像垃圾......如果你真的很聪明，你可以窥探正在使用的（不正确的）密钥。我会避免任何注入人类可读字符串的东西，因为它们总是会引起人们对那段代码的注意。

于 2011-05-20T09:34:11.713 回答