如何检测 Java 代理、JVMTI 等答案

【问题标题】：How to detect Java agents, JVMTI, etc如何检测 Java 代理、JVMTI 等
【发布时间】：2011-02-15 23:07:37
【问题描述】：

在您无法控制的机器上运行时如何保护 Java 环境？什么是阻止某人创建 Java 代理或本机 JVMTI 代理并转储字节码或重写类以绕过许可和/或其他安全检查？有什么方法可以检测是否有任何代理从 Java 代码运行？来自 JNI？来自 JVMTI 代理？

【问题讨论】：

@Andrew Westberg：如果您不希望人们检查您的代码，请让您的代码基于服务器。让计算发生在服务器端：没有人对 GMail 的服务器端代码进行逆向工程，因为它是发生在服务器端的。这对你来说可能不实用，但对我公司来说肯定是;)
底线：如果你不控制机器，你就没有真正的控制权。没有办法解决这个问题。你可以给那些试图这样做的人设置一些障碍。但我不相信你的努力值得。

标签： java security agent bytecode-manipulation jvmti

【解决方案1】：

如果你不控制环境，那么对不起 - 你真的被卡住了。是的，您可以通过某种 cmdline 嗅探来寻找琐碎的 JVMTI 代理，但这是您最不必担心的问题。想想 java/lang/Classloader.defineClass() 被直接破坏了。如果您拥有该盒子，这很容易做到 - 只需替换 rt.jar 中的 .class 文件。事实上，在 JVMTI 出现之前，这是分析器和监控工具检测 Java 代码的典型方式。

回到 JVMTI——“延迟附加”功能还允许动态加载 JVMTI 代理。第一次扫描时可能不会发生这种情况。

底线 - 如果有人可以更改磁盘上 JRE 的字节，他们可以做任何他们想做的事情。这合乎道德，不是吗？他们能被抓住吗？有可能，但你永远不会赢得战争。

【讨论】：

我不使用 ClassLoader.defineClass()，所以我在那里不会受到攻击。我通过 JNI 将字节码直接注入到本机 java.dll 中。
我不明白为什么。你认为你通过 java.dll 有什么魔力？我想 java.dll 会转过来并通过 java 回调来执行此操作，所以我怀疑您通往 jvm.dll（JVM 真正所在的位置）的路径是否像您想象的那样干净。但是关于无法信任的问题仍然存在：java.dll 本身可能会受到损害，因为您不拥有它。或 jvm.dll。两者都可以被“中间人” DLL 替换，这些 DLL 监视/操作通过它们的所有调用。

【解决方案2】：

看起来我可以在一些自定义 JNI 本机代码中进行组合检查。

1.) 命令行嗅探以搜索代理。 2.) 确保命令行参数 -XX:+DisableAttachMechanism 存在。（这将防止人们附加到我正在运行的 VM）

【讨论】：

【解决方案3】：

我记得我曾经制作了一个几乎无声的 Java 代理。我想你最好寻找端口扫描器或其他类似的东西。

【讨论】：

【解决方案4】：

Java 2 安全性、jar 签名等，可以在一定程度上控制加载到应用程序中的内容。

但最终，如果恶意人员可以访问一台机器以便他们可以写入磁盘，那么他们很可能有足够的能力造成伤害，而无需求助于聪明的 Java hack。

转过头来，用任何语言你能做些什么来检测特洛伊木马？

对您关心的机器进行仔细的访问控制并非易事，但如果您认真对待此类问题，则必不可少。安全专家可能看起来偏执，但这通常意味着他们真正了解风险。

【讨论】：

【解决方案5】：

如果你不能控制平台，你就不能控制上面的软件。

即使您可以关闭您列出的所有检查途径，Java 也是开源的。他们可以直接获取源代码并使用内置的必要更改重新编译它。

另外，请记住，虽然它是您的代码，但它是他们的机器。他们有权检查您的代码，以验证在他们的机器上运行它是否符合他们的预期，并且不会执行他们可能认为不受欢迎的“额外”操作。过去不太值得信赖的公司会扫描不相关的文件，将敏感信息复制回其家庭服务器等。

【讨论】：

我不买整个“他们有正确的”东西。至少不是根据现行的美国版权法。如果我要向他们颁发使用我的软件的许可证，我需要让他们放心，他们不能简单地绕过我在 Java 平台上的许可。
版权意味着他们不能制作未经授权的副本，而不是他们不能检查原件。许可证可能会对软件的使用提出条款，并且可能应该包括限制逆向工程、规避许可代码等的条款。但是，您是在许可使用您的软件，而不是使用它们的硬件或 JVM。也就是说，这是一种法律解决方案，而不是技术解决方案。从技术上讲，除非您提供带有签名 BIOS 和加密硬盘的封闭式硬件解决方案，否则无法做到这一点，即使这样（XBOX）您的一个小错误也可能会打开代码。

【解决方案6】：

我会查看命令行，看看是否有任何“-agent”参数。所有分析器、调试器和其他代码修改器都使用它进行自省。您还可以检查引导类路径上的异常 jar，因为它们也可能构成威胁（但请注意，您还必须提供自定义 JVM，因为 Quicktime 等某些软件会将自身添加到所有运行的 Java 应用程序的引导类路径中...... （当我看到那个时，我简直不敢相信自己的眼睛......））

【讨论】：

我喜欢扫描 cmd 行并寻找 -agent 的想法。那么动态附加代理呢？有什么方法可以从本机代码中检测到这些吗？
看看 visualvm 如何附加到正在运行的 JVM 并允许进行动态分析。命令行分析永远无法捕捉到这一点。
必须启用要附加 JMX 的可视 vm。他也可以检查一下。
什么命令行？在 Java 中，您无法访问提供给 VM 的参数。
@Daniel 不，visualvm 可以附加到任何正常启动的 Hotspot JVM

【解决方案7】：

基本上这是一场失败的战斗。

看看 Sun JDK 中的 visualvm 是如何工作的，以及它如何附加到正在运行的进程并重新定义它所需要的一切。以可移植的方式检测到这一点非常困难，除非你能做到，否则你还不如放弃这种方法。

问题是，你想避免什么？

【讨论】：

-XX:+DisableAttachMechanism 看起来可以防止动态附加。
@AndrewWestberg 有没有办法在 Java 应用程序启动后以编程方式禁用附加机制？也许通过 jmx？
@opeongo 这个问题已经 8 年了，所以我已经有一段时间没有在这个环境中工作了。除了命令行之外，我不知道有任何方法可以禁用附加。