如何保护解密密钥不被反编译？
我是一名初学java程序员。我正在开发一个解密一些数据的应用程序。 解密密钥被硬编码到软件中，因此可以通过分析字节码看到。
我知道逆向工程是无法完全阻止的，所以我正在尝试做的是让这个过程尽可能困难。
我的想法不是直接将密钥放入我的代码中，而是让它经过某种转换。 例如，我可以写 -
private static final byte[] HC256A = Hex
.decode("8589075b0df3f6d82fc0c5425179b6a6"
+ "3465f053f2891f808b24744e18480b72"
+ "ec2792cdbf4dcfeb7769bf8dfa14aee4"
+ "7b4c50e8eaf3a9c8f506016c81697e32");
这样查看字节码的人无法立即读取它。但必须遵循逻辑并对它应用转换，这在字节级别不会那么容易。
那么你们觉得怎么样？这有用吗？除了十六进制解码之外，最好的转换是什么？ 是否有其他方法可用于保护硬编码解密密钥？
感谢您的所有建议。
I'm a beginner java programmer. I'm working on an application that decrypts some data.
The decryption key is hardcoded into the software and thus can be seen by analyzing the bytecode.
I know that reverse engineering cannot be prevented entirely so what I'm trying to do is to make the process as hard as possible.
My idea is not to directly put the key into my code but have it go through some kind of transformation.
For example, I could write -
private static final byte[] HC256A = Hex
.decode("8589075b0df3f6d82fc0c5425179b6a6"
+ "3465f053f2891f808b24744e18480b72"
+ "ec2792cdbf4dcfeb7769bf8dfa14aee4"
+ "7b4c50e8eaf3a9c8f506016c81697e32");
This way someone looking at the bytecode can't read it straight away. But will have to follow the logic and apply transformations to it, which won't be that much easier at byte level.
So what do you guys think? Is this useful? What could be the be the best transformation other than hex decoding?
Are there any other methods available to protect hardcoded decryption keys?
Thanks for all your suggestions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
攻击这种混淆的正确方法（尤其是在字节码语言中）是将调试器附加到密钥传递到的位置（如果无法进行调试，请从该位置开始分析代码）。这样攻击者根本不需要寻找密钥，也不在乎密钥有多模糊。所以你需要重新思考你的设计。
如果您只想防止业余潜伏者，那么拆分密钥并对其各个部分进行异或（可能使用不同的密钥）就足够了。还有一个技巧 - 从代码中已存在的文本常量（例如应用程序名称）中派生密钥。这使得密钥不像分裂或异或那么明显。
Right way to attack such obfuscation (especially in bytecode languages) is to attach debugger to the place to which the key is passed (if debugging is not possible, start analyzing code from that place). This way the attacker doesn't need to look for the key at all and he doesn't care how obfuscated the key is. So you need to re-think your design.
If you only want to protect from the amateur lurkers, then splitting the key and XORing it's parts (possibly with different keys), would be enough. One more trick - derive the key from text constants already present in the code (such as application name). This makes the key less obvious than splitting or XORing.
根本不要将密钥编码到源代码中。将其分开，单独发送，例如在 Java 密钥库中，并且仅发送给您信任的客户/站点/客户，并在许可证中添加一些法律术语，如果他们泄漏密钥库，则将承担责任。
Don't code the key into the source code at all. Keep it separate, ship it separately, e.g. in a Java keystore, and only to customers/sites/clients you trust, and put some legalese in the licence that places the onus on them if they leak the keystore.
面对类似的问题（在 c 中），我使用了一次性 XOR 垫。这很好，因为它看起来像垃圾......如果你真的很聪明，你可以窥探正在使用的那个（不正确的）密钥。我会避免任何注入人类可读字符串的东西，因为它们总是会引起人们对那段代码的注意。
Faced with a similar problem (in c) I went with single use XOR pads. This is good because it looks like garbage... if you get really clever you can snoop for that (incorrect) key in use. I would avoid anything that injects human readable strings as those will invariably draw attention to that bit of code.