黑客校对 jar 文件
我可以使用哪些技术来使我的“jar”文件进行逆向工程证明？
What techniques could I use to make my "jar" file Reverse Engineer proof?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我可以使用哪些技术来使我的“jar”文件进行逆向工程证明？
What techniques could I use to make my "jar" file Reverse Engineer proof?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
不要释放它。
Don't release it.
不存在所谓的黑客证明。对不起。
编辑评论：
不幸的事实是，无论你设置什么路障，如果诚实地想要进入，他们就会进入。仅仅因为如果他们足够持久，他们就会从程序集中查看你的代码等级。你对此无能为力。
您可以考虑做的是混淆代码，打包 jar 并将所有外部包合并到一个单独的包中，以使生活变得更加困难。然而，无论障碍有多高，我在上一段中的评论仍然适用。
There is no such thing as hacker proof. Sorry.
EDIT FOR COMMENT:
The unfortunate truth is that no matter what barricade you put in the way, if the honestly want in, they'll get in. Simply because if they're persistent enough they'll be looking at your code from an Assembly level. Not a thing on earth you can do about it.
What you can look at doing is Obfuscating code, packing the jar and merging all externals packages into a single to make life harder. However no matter how high the hurdle, my comment in the previous paragraph still applies.
我认为这更多的是强化 jar 的访问路径，而不是其他任何事情。
实际上会执行代码
这将访问 .jar。锁
将 jar 的访问权限设置为只读
仅由该用户访问。你如何做到这一点
将取决于您是否使用来自的罐子
一个网络应用程序或一个桌面.exe，它也将
取决于您正在运行的操作系统
在下面。
验证来自的签名
可执行代码。这至少会
告诉你 .jar 是否已经存在
被篡改。然后你就可以拥有
一些停止正在执行的应用程序的逻辑
避免使用 .jar（并记录并显示错误）。
有关详细信息，请参阅 jarsigner 文档。
I think this is more about hardening the access path to the jar, more than anything else.
will actually be executing the code
that will access the .jar. Lock
down access to the jar to read-only
access from only that user. How you do this
will depend on if you're using the jar from
a web app or a desktop .exe, and it will also
depend on the operating system you're running
under.
validate the signature from the
executable code. This will at least
tell you if the .jar has been
tampered with. You can then have
some logic to stop the executing application
from using the .jar (and log and display an error).
See jarsigner docs for more information.
我见过一个案例，一家公司编写了一个自定义类加载器，可以解密加密的 jar 文件。类加载器本身使用编译的 JNI 代码，因此解密密钥和算法在二进制库中被相当深度地混淆。
I have seen one case where a company wrote a custom classloader, that could decrypt an encrypted jar file. The classloader itself used compiled JNI code, so that the decryption key and algorithm were fairly deeply obfuscated in the binary libary.
您正在寻找一个“混淆器”（如果您想运送罐子）。许多存在：
http://java-source.net/open-source/obfuscators
您应该意识到，许多混淆技术会删除您可能想要保留的用于故障排除目的的信息 - 考虑来自不可重现情况的堆栈跟踪的价值 - 或实际调试会话。无论您做什么，您的质量测试都应该在要发货的罐子上进行，因为混淆器可能会引入微妙的错误。
如果您确实想隐藏某些内容，请考虑使用 gcj 编译为本机二进制文件。
You are looking for an "obfuscator" (if you want to ship jars) . Many exist:
http://java-source.net/open-source/obfuscators
You should be aware that many obfuscation techniques removes information you may want to keep for troubleshooting purposes - think of the value of a stack trace from an irreproducible situation - or actual debugging sessions. Regardless of what you do, your quality testing should be done on the jars-to-be-shipped since the obfuscator may introduce subtle bugs.
If you really want to hide things, consider compiling to an native binary with gcj.
绝对避免在代码中放置任何敏感数据。例如：
一种选择是对这些内容进行加密（使用行业标准加密例程；避免自行创建）并将它们放置在外部配置文件或数据库中。
正如其他人所说，部署代码中的任何算法都可以进行逆向工程。
如果需要，可以将敏感算法放置在 Web 服务或其他服务器端代码中。
Definitely avoid placing any sensitive data in the code. For example:
One option would be to encrypt these (using industry-standard encryption routines; avoid rolling your own) and place them in an external configuration file or database.
As others have stated, any algorithms in deployed code can be reverse-engineered.
Sensitive algorithms could be placed in a web service or other server-side code if desired.
你无法对其进行逆向工程证明。如果 java 运行时可以读取指令，那么用户也可以。
有些混淆器会使反汇编代码的可读性/理解性降低，从而使逆向工程变得更加困难，但你不能让它变得不可能。
You can't make it reverse engineer proof. If the java runtime can read the instructions, so can the user.
There are obfuscators which make the disassembled code less readable/understandable to make reverse engineering it harder, but you can't make it impossible.