[!WARNING] Final verdict available at the end of this report.
The scanner inspected all 521 classes in HolyEnchantments.jar, including 4,944 methods. All classes parsed successfully, and all 521 classes were sent through decompilation. There were no suspicious archive entries and only one decompiler anomaly caused by a complex method timing out during a pre-check.
The report contains 78 suspicious classes, or about 15% of the JAR. Most of these belong to bundled or relocated libraries, especially Javassist, Java-WebSocket, and SLF4J. The scan detected file access, reflection, class loading, HTTP, socket, and WebSocket APIs. These indicators can be normal in libraries, but the plugin-specific classes and the external WebSocket address require closer inspection.
No high-signal malicious behavior was detected in the supplied report.
The scan does not report credential theft, password or token grabbing, process execution, persistence mechanisms, destructive commands, hidden downloads, or obvious data exfiltration. It also does not identify a malicious archive entry.
There are, however, network and filesystem indicators. In particular, the report references a WebSocket endpoint at http://client.hostflow.eu:5050/ws and a public IP-check service at http://checkip.amazonaws.com. The report does not establish what information is sent to the WebSocket service or whether this behavior is required by the plugin.
The evidence is not sufficient to classify this JAR as a remote-access trojan. WebSocket and socket support can be used for legitimate plugin communication and does not automatically mean remote control.
The client.hostflow.eu:5050/ws endpoint is still an unresolved concern because it appears alongside filesystem enumeration and network code. The report does not show command execution, persistence, remote shell functionality, or a clear command-and-control protocol.
| Class | Severity | Behavior | Evidence |
|---|---|---|---|
org.dimasik.holyenchantments.HolyEnchantmentsL10 |
Medium | Reads files and enumerates filesystem contents | Uses Java file, NIO, and filesystem-enumeration APIs in a(String) |
org.dimasik.holyenchantments.enchantscore.EnchantsMap |
Low/Medium | Performs file access during plugin setup | Uses Java file and NIO APIs in its constructor |
These are the plugin’s own classes rather than obviously standard library packages. File access may be normal for loading enchantment data, configuration, or plugin storage, but the report does not provide enough method-level detail to confirm the exact purpose of the filesystem enumeration.
| Class or group | Severity | Behavior | Evidence |
|---|---|---|---|
javassist.* |
Low/Medium | Reflection, class loading, bytecode generation, file and URL access | Many classes use class loaders, reflection, URLs, or filesystem APIs |
javassist.orgs.java_websocket.* |
Medium | WebSocket and socket communication | Includes WebSocket clients, servers, socket channels, and connection handling |
javassist.ws.* |
Medium/High | WebSocket communication, IP lookup, and filesystem enumeration | References client.hostflow.eu:5050/ws, checkip.amazonaws.com, and file enumeration |
javassist.orgs.slf4j.* |
Low | Logging framework behavior and documentation URLs | References normal SLF4J diagnostic URLs such as www.slf4j.org/codes.html |
javassist.util.proxy.* |
Low | Reflection and dynamic class generation | Uses class loaders, reflection, method handles, and generated bytecode |
The javassist.orgs.* naming suggests that third-party libraries were relocated or shaded into the JAR. Javassist commonly uses class loaders, reflection, generated classes, URLs, and file APIs. Java-WebSocket naturally contains socket and WebSocket operations. These indicators should not be treated as malware merely because the scanner labels them suspicious.
The more important item is javassist.ws.a, which combines library-like WebSocket code with a specific external service, an IP lookup, and filesystem enumeration. The package name alone does not prove whether this is an unmodified dependency or custom code bundled into the plugin.
The report lists these destinations:
github.com — a Java-WebSocket documentation link about lost-connection detection. This appears to be a reference URL, not necessarily an active connection.www.slf4j.org — standard SLF4J diagnostic and logging documentation URLs. These are common in logging libraries.checkip.amazonaws.com — an external service that returns the machine’s public IP address.client.hostflow.eu:5050/ws — an external unencrypted WebSocket endpoint.The scanner detected Java URL, URL-connection, HTTP, WebSocket, and socket APIs. The public IP lookup may be used to identify the server’s external address. The WebSocket endpoint is the least explained network indicator because the report does not say what data is transmitted or why the enchantment plugin needs a persistent WebSocket connection.
No IP addresses were listed directly in the report, apart from the hostname-based endpoints above.
The one anomaly occurred in javassist.orgs.java_websocket.d, where method private boolean d() exceeded a complexity guard. The method had short names and missing local-variable metadata, but the scanner did not report broad or heavy obfuscation.
Overall, the JAR was successfully inspected. The anomaly is not, by itself, evidence of malware.
This appears to be a Minecraft server plugin because the package contains org.dimasik.holyenchantments and the file is named HolyEnchantments.jar.
The normal parts of the plugin likely include loading enchantment data, writing or reading plugin files, and using Java libraries. However, an enchantment plugin would not obviously need a public-IP lookup or an external WebSocket connection unless it provides a licensing, update, analytics, remote status, or management feature. That purpose should be confirmed with the plugin author or its official documentation.
www.slf4j.org URLs are standard troubleshooting links embedded in the logging framework.http://client.hostflow.eu:5050/ws, an external WebSocket service.http://checkip.amazonaws.com, which can reveal the server’s public IP address to an outside service.javassist.ws code combines network communication with filesystem enumeration. The report does not explain whether this is a legitimate feature or what data may be sent.There are no reported signs of credential theft, process execution, persistence, destructive activity, hidden downloads, or remote command execution.
client.hostflow.eu:5050 or checkip.amazonaws.com.0522d46b7bd48387d7d03ac7d3160990efe6e594c9767e1a7af67e8839638ef7Static JAR scanning examines code structure and recognizable behavior; it does not prove that a file is completely safe. It may not determine what data is sent at runtime, whether behavior depends on server responses, or whether a legitimate library has been modified internally. Runtime monitoring, provenance checks, and testing in an isolated environment provide additional protection.
Yes. A JAR can contain malicious Java code just like other executable file formats. This scan found no high-signal malware behavior, but a static scan cannot guarantee complete safety.
Check its source and publisher, compare its hash with an official release, inspect scanner results, review network destinations, and test it in an isolated environment. For this JAR, pay particular attention to the Hostflow WebSocket endpoint and the public-IP lookup.
It can detect many signs associated with RATs, such as command execution, suspicious network control, persistence, and credential access. It cannot reliably identify every RAT, especially if behavior is encrypted, delayed, server-controlled, or hidden behind legitimate libraries.
No. Obfuscation and short names can be used to protect intellectual property or reduce file size. In this report, only one complex method triggered a decompiler anomaly, which is not enough to establish malicious intent.
Verdict: Use caution
Risk level: Moderate
Confidence: Moderate
Should I trust this JAR, and why? The scan successfully inspected the entire JAR and found no evidence of credential theft, destructive commands, persistence, hidden downloads, or process execution. Most suspicious findings come from bundled Javassist, Java-WebSocket, and SLF4J libraries, where the flagged APIs can be normal. However, plugin-bundled code references an unexplained external WebSocket service and a public-IP lookup while also enumerating files, so the network behavior should be verified before using it on a production server. I would not run it on a trusted server until that communication is confirmed as an intended feature by the publisher.