黑客对 jar 文件进行校对答案

【问题标题】：Hacker proofing a jar file黑客对 jar 文件进行校对
【发布时间】：2009-09-06 01:00:06
【问题描述】：

我可以使用哪些技术来证明我的“jar”文件逆向工程师证明？

【问题讨论】：

stackoverflow.com/questions/1146855/…
我知道做一些“防黑客”的东西是不可能的，我理解使用这种不准确的短语的危险，我知道人们可能会采取许多措施来“防黑客”自己的罐子是坏主意。但是，这可能不是 OP 的选择。当对如何使入侵变得更加困难的解释会更有帮助时，关于 SO 的太多安全问题会以“这是不可能的”来回答。是的，人们需要知道什么时候完全安全是不可能的，但如果这就是你必须提供的全部，那只是部分答案。
@imagist “我知道人们可能会采取许多措施来“防黑客”自己的罐子都是坏主意“为什么？
您能否编辑您的答案以准确解释您想避免哪种情况？
正如之前多次声明的那样，没有什么可以阻止真正执意要反转您的代码的人反转它。我只是在阅读一个不同的问题，它向我展示了这个链接：java.decompiler.free.fr。如果您在用户的机器上运行代码，他们可以反转它。这只是生活中的事实。

【解决方案1】：

您无法对其进行逆向工程证明。如果 java 运行时可以读取指令，那么用户也可以。

有些混淆器会降低反汇编代码的可读性/可理解性，从而使逆向工程变得更加困难，但你不能让它变得不可能。

【讨论】：

就像你不能让机器编译的代码“防黑客”一样——你可以简单地混淆它。
有一种方法——首先确保用户永远无法访问 .jar 文件。例如，一些应用程序只下载一个“客户端”给用户，为了访问超级机密算法，客户端必须将处理请求发送到服务器（由开发人员拥有，并且希望是安全的）。对客户端的数据运行密码并将结果发回。
@Jeremy - 只要有足够的时间，即使是服务器端算法也可能被破坏。
@aaron：是的，但你只需要更新它，或者更改一个被泄露的密钥——你没有交付你无法控制执行的产品。

【解决方案2】：

不要释放它。

【讨论】：

几乎 100%，只要没有人拿到您的磁盘。最好将其归零并将其扔进火中以完全确定。
克林贡语不“发布”软件。克林贡软件逃跑了，留下了设计工程师和质量保证人员的血腥痕迹。来自klingon.org/resources/klingon_code.html

【解决方案3】：

没有黑客证明这回事。对不起。

编辑评论：

不幸的事实是，无论您设置什么路障，如果真诚地想要进入，他们就会进入。仅仅是因为如果他们足够持久，他们会从汇编级别查看您的代码.对此你无能为力。

您可以做的是混淆代码、打包 jar 并将所有外部包合并到一个单独的包中，以使生活更加艰难。但是，无论障碍有多高，我在上一段中的评论仍然适用。

【讨论】：

【解决方案4】：

我认为这更多是关于强化 jar 的访问路径，而不是其他任何事情。

尝试确定用户上下文实际上将执行代码这将访问.jar。锁对jar的访问权限为只读仅来自该用户的访问。你如何做到这一点将取决于您是否使用来自 Web 应用程序或桌面 .exe，它也将取决于您正在运行的操作系统下。
如果可能的话——在罐子上签名并验证来自的签名可执行代码。这至少会告诉你 .jar 是否已经篡改。然后你可以有一些逻辑来停止正在执行的应用程序使用 .jar （并记录并显示错误）。请参阅jarsigner docs 了解更多信息。

【讨论】：

【解决方案5】：

我见过一个案例，一家公司编写了一个自定义类加载器，它可以解密一个加密的 jar 文件。类加载器本身使用编译的 JNI 代码，因此解密密钥和算法在二进制库中被相当深入地混淆。

【讨论】：

不过，这似乎是一个糟糕的解决方案，因为它会使您的便携性陷入地狱。
一切都是妥协。在这种情况下，该公司希望将他们的产品在选定的平台上推向市场，同时仍然保护他们的 IP，并在付费客户需要他们的产品在另一个平台上时解决可移植性问题。这个类加载器是他们唯一拥有的 JNI，其余代码都是纯 Java。所以是的，“可怕”，因为它将他们绑定到一个特定的平台，但不，不是那么“可怕”，因为他们把他们的产品拿出来并且仍然感到安全，他们没有泄露秘密调味料。
"...并且仍然感到安全..."。感到安全和安全是完全不同的事情:-)

【解决方案6】：

您正在寻找“混淆器”（如果您想运送罐子）。许多存在：

您应该知道，许多混淆技术会删除您可能出于故障排除目的而需要保留的信息 - 从不可重现的情况或实际调试会话中考虑堆栈跟踪的价值。无论您做什么，都应该对要发货的 jar 进行质量测试，因为混淆器可能会引入细微的错误。

如果你真的想隐藏东西，可以考虑用 gcj 编译成原生二进制文件。

【讨论】：

【解决方案7】：

绝对避免在代码中放置任何敏感数据。例如：

一种选择是加密这些（使用行业标准的加密例程；避免自己滚动）并将它们放在外部配置文件或数据库中。

正如其他人所说，已部署代码中的任何算法都可以进行逆向工程。

如果需要，可以将敏感算法放置在 Web 服务或其他服务器端代码中。

【讨论】：

无法理解“避免滚动自己”。为什么？
见stackoverflow.com/questions/118374/… - 跳过接受的答案并阅读其他答案。（公认的答案基本上是“为了好玩而做”——但不是为了生产代码。）大多数人都陷入了隐匿安全的陷阱——而且，如上所述，你的算法可以被逆向工程。
即使是放在服务器端的算法也可能被破坏。