让你的Jar不被反编译
如何将我的 Java 应用程序打包到无法反编译的可执行 jar 中（例如，通过 Jadclipse）？
How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你不能。 如果 JRE 可以运行它，应用程序就可以反编译它。
您所能期望的最好的结果就是让它变得非常难以阅读（用“l”和“1”以及“O”和“0”的组合替换所有符号，放入大量无用的代码等等）。 你会惊讶地发现，即使使用相对愚蠢的翻译工具，你也可以编写出如此难以阅读的代码。
这称为混淆，虽然并不完美，但有时已经足够了。
请记住，你无法阻止意志坚定的黑客，就像你无法阻止意志坚定的窃贼一样。 你要做的就是让偶然的攻击者变得非常困难。 当出现符号
O001l1ll10O、O001llll10O、OO01l1ll10O、O0Ol11ll10O和O001l1ll1OO时，如果代码看起来没有任何用处，大多数人就会放弃。You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols
O001l1ll10O,O001llll10O,OO01l1ll10O,O0Ol11ll10OandO001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.首先，你无法避免人们对你的代码进行逆向工程。 JVM 字节码必须简单才能执行，并且有多个程序可以对其进行逆向工程（同样适用于 .NET CLR）。 你只能让查看和理解你的代码的障碍（即成本）变得越来越困难。
通常的方法是使用某种工具混淆源代码。 整个代码库中的类、方法和字段都会被重命名，即使您选择使用无效的标识符，也会使代码几乎无法理解。 我过去使用 JODE 取得了很好的效果。 混淆后，使用反编译器查看代码的样子...
接下来进行混淆，您可以使用某种方法加密您的类文件（除了一个小的入门类之外的所有文件），并使用自定义类加载器来解密它们。 不幸的是，类加载器类本身无法加密，因此人们可能通过阅读类加载器的反编译代码来找出解密算法。 但攻击代码的窗口变小了。 同样，这并不能阻止人们看到您的代码，只是让临时攻击者更难。
您还可以尝试将 Java 应用程序转换为某些 Windows EXE，这将隐藏它根本是 Java 的线索（在某种程度上）或真正编译为机器代码，具体取决于您对 JVM 功能的需要。 （我没有尝试这个。）
First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)
GCJ 是一个免费工具，可以编译为字节码或本机代码。 请记住，这确实违背了 Java 的目的。
GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.
我知道的有点晚了，但答案是否定的。
即使您用 C 语言编写并编译为本机代码，也有反汇编器/调试器允许人们单步执行您的代码。 当然，在没有符号信息的情况下调试优化代码是一件痛苦的事情，但它是可以做到的，我有时不得不这样做。
您可以采取一些步骤来增加此操作的难度 - 例如，在 Windows 上，您可以调用 IsDebuggerPresent API 在循环中查看是否有人正在调试您的进程，如果是并且它是发布版本 - 终止该进程。 当然，意志坚定的攻击者可能会拦截您对 IsDebuggerPresent 的调用并始终返回 false。
出现了各种各样的技术——想要保护某物的人和想要将其彻底破解的人，这是一场名副其实的军备竞赛！ 一旦你走上这条路 - 你将不得不不断更新/升级你的防御，没有停止。
A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.
这不是我的实际解决方案，但是，我认为这里有很好的收藏或资源和教程，可以使其达到最高的满意度。
来自此网站的建议（Oracle 社区）
下面是一步一步的操作：
保护您的JavaCode
享受吧！
添加您的解决方案，我们更需要这个。
This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.