我可以使用本机编译作为 Java 混淆吗答案

【问题标题】：Can I use native compilation as Java obfuscation我可以使用本机编译作为 Java 混淆吗
【发布时间】：2019-01-16 03:18:06
【问题描述】：

我正在为 Java 应用程序编写插件。我可以混淆插件，但它仍然很容易被逆向工程。

我相信，如果我可以将此插件编译为一个共享库，该库大量使用 JNI 与主应用程序通信，那么逆向工程将更加困难。我愿意为 JNI 牺牲一些性能，而我正在编写的应用程序确实支持共享库加载。唯一的问题是我不知道有什么工具可以完成这项工作：gcj 似乎依赖于它自己的运行时和 IKVM.NET - on .NET

准确地说：


public class PluginImpl implements Plugin {
    @Override
    public void startPlugin(PluginContext ctx) {
       ctx.helloWorld();
    }  
}

应该转换成


public class PluginImpl implements Plugin {
    @Override
    public native void startPlugin(PluginContext ctx);
}

我的 startPlugin 方法的主体被编译成一个共享库。

（嗯，是的，我知道，我本来可以用 C 语言编写这个插件）

【问题讨论】：

为什么说混淆后的字节码很容易被逆向工程？
任何有时间和耐心去混淆你的字节码的人都可以对原生代码做同样的事情，只要有更多的时间。您正在牺牲性能、无法调试、可靠性（当编译为本地的 Java 与在 JVM 中运行时总是表现不同时）以及您自己的时间，以换取很少的“收益”和非常劣质的产品。 现在放弃，虽然您还没有在混淆方面投入太多时间，以至于您觉得自己只是必须像这样发布产品...
也许你应该把你的应用移植到 Perl ;-)
我认为，如果这种方法很容易实现自动化和成功，那么早就有人将其变成商业混淆产品了。 :)

标签： java java-native-interface native

【解决方案1】：

我认为您有充分的理由进行本机编译。您可以检查的一个选项是 Excelsior JET，它是经过认证的 Java 解决方案。

【讨论】：

它仍然运行自己的运行时：“生成的可执行文件需要 Excelsior JET 运行时才能运行，而不是 Sun JRE。” (excelsior-usa.com/jetfaq.html)
好吧，无论如何，+1 是因为它是一个非常有趣的产品。
任何 Java 应用程序都需要带有垃圾收集器、上下文隔离（无论是 JNI、CNI 还是其他）等的 Java 运行时。Excelsior JET 只是将字节码预编译为优化的本机代码。它仍然有一个 JIT 编译器来处理未预编译的类 - 动态代理、第三方插件等等。

【解决方案2】：

您可以让您的插件通过RMI 提供服务。这样，插件将成为一个应用程序，并且可以编译为本机代码。

【讨论】：

真的很好，谢谢。我怀疑进程外 RMI 对性能的影响太大，但我可以试一试。额外的好处是我可以使用 gcj 。我希望我编写的 API 对序列化更友好。

【解决方案3】：

如果您以任何形式分发可执行代码，则不能真正使用 anything 进行代码混淆。任何可执行代码都可以进行逆向工程。这是一个商业问题而不是技术问题，它通过商业手段来解决：许可协议、价格、上市时间，或者很可能是对风险和价值的更现实的评估，即承认你的代码只是' t那么有价值。或者，将您的产品作为服务而不是可执行文件提供。

【讨论】：

混淆并不是为了“防止”逆向工程，只是为了让它变得更加困难。只要您知道，如果您分发可执行代码实际上不可能完全防止逆向工程，那么使用混淆作为威慑就没有错。
有一定的成本和可能的收益。这是一个商业决策。
您可以对任何软件产品的任何功能说同样的话。决定是否实现该功能是一项业务决策。设计和实施是一项技术工作。同样，决定是否使用混淆是一个业务问题。混淆本身就是一个技术话题。
@Grodriguez：混淆使逆向工程更加耗时 - 确实{但不是太多}，也为开发人员的亲属提供了良好的祈祷，但最终一无所获。
@bestsss：您在谈论“破坏许可证”。这与我的论点无关。我从来没有说过混淆对于防止复制保护很有用。我说它使逆向工程变得更加困难。它的作用。