Can I use native compilation as Java obfuscation

Question

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

我认为如果我能将此插件编译成共享库，并使用JNI与主应用程序进行通信，那么它将更难被逆向工程破解。我愿意为JNI牺牲一些性能，并且我正在编写的应用程序支持共享库加载。唯一的问题是我不知道有什么工具可以完成这项工作：gcj似乎依赖于自己的运行时，而IKVM.NET则依赖于.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语言编写这个插件的)

- obfuscer

---

为什么你说混淆的字节码容易被反向工程化？ - hhafez

只要有时间和耐心来解密你的字节码，人们也可以用更多的时间来解开原生代码。你为了一个微不足道的“优势”以及极低质量的产品，牺牲了性能、无法调试、可靠性（当编译成本地Java后，与在JVM中运行时表现不同），还有自己数天的时间。现在就放弃吧，除非你已经投入了很多时间进行混淆，感觉必须这样发布产品... - SimonJ

也许你应该将你的应用程序移植到 Perl ;-) - helpermethod

我认为如果这种方法容易自动化并实现，那么有人已经将其转化为商业混淆产品了。 :) - Mike Clark

Answer 1

如果你以任何形式分发可执行代码，那么实际上不能使用任何东西进行代码混淆。任何可执行代码都可以被反向工程。这是一个商业问题而不是技术问题，并且可以通过商业手段来解决：许可协议、价格、上市时间或者更现实的风险和价值评估，即承认你的代码并不那么有价值。或者，将产品作为服务而不是可执行文件交付。

- user207421

---

混淆并非旨在"防止"反向工程，而只是使其更加困难。只要您知道如果分发可执行代码则无法完全阻止反向工程，使用混淆作为威慑措施就没有任何问题。 - Grodriguez

有明确的成本和可能的收益。这是一个商业决策。 - user207421

@Grodriguez：混淆使得逆向工程更加耗时 - 这是真的{但不会太多}，同时为开发人员的亲属提供了良好的祈祷，但最终却一无所获。 - bestsss

@bestsss：定义"break"。与其他保护措施不同，混淆根本不需要被“破解”。混淆的整个重点在于，即使您完全访问（混淆的）源代码，您仍然会很难弄清楚它的工作原理。 - Grodriguez

@bestsss：你在谈论“破解许可证”。这与我的论点无关。我从未说过混淆有助于防止复制保护。我说的是它使反向工程更加困难。而它确实如此。 - Grodriguez

Answer 2

我假设你有选择原生编译的充分理由。你可以考虑的一个选项是Excelsior JET，这是一种经过认证的Java解决方案。

- renick

---

它仍然运行自己的运行时："生成的可执行文件需要Excelsior JET Runtime才能运行，但不需要Sun JRE。"（http://www.excelsior-usa.com/jetfaq.html） - obfuscer

无论如何，因为是一个非常有趣的产品，我还是给它点赞。 - Mike Clark

任何Java应用程序都需要具备Java运行时环境，包括垃圾回收器、上下文隔离（无论是JNI、CNI还是其他什么），等等。Excelsior JET只是将字节码预编译为优化的本地代码。它仍然具有JIT编译器来处理未预编译的类，如动态代理、第三方插件等。 - Dmitry Leskov

Answer 3

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

- josefx

---

非常好的观点，谢谢。我怀疑进程外RMI会有太多的性能损失，但我可能会尝试一下。额外的好处是我可以使用gcj。我希望我正在编写的API更加友好地支持序列化。 - obfuscer