[!WARNING] Final verdict available at the end of this report.
This JAR scanner inspected all 70 classes in xercapaint-1.21.11-smponline-1.0.0.jar, including all 536 methods containing code. Every class parsed and decompiled successfully, with no archive-entry warnings and no decompiler anomalies. This gives the report full static-code coverage rather than relying on partial inspection.
Two classes were flagged for closer review. Both findings involve file-system access: one client-side mod class can access and enumerate files, while a packet handler can use Java’s file APIs. The client class also uses Base64 and cryptography-related APIs, which can be normal for encoding, validation, or protected data handling but deserve context.
The scan found no URLs, domains, IP addresses, or indicators of outbound connections. The evidence below is important because file access can be appropriate for a painting-related Minecraft mod, but it should be assessed separately from network, command-execution, and data-theft behavior.
No high-signal malicious behavior was detected.
The report contains no evidence of credential or token theft, hidden payload downloads, command or process execution, persistence mechanisms, destructive file operations, outbound data exfiltration, or embedded suspicious archive content. No network endpoints, URLs, hosts, or outbound-connection indicators were found.
The flagged behavior is limited to file access in two classes and Base64/cryptography API use in one client-side class. Those are not enough on their own to identify malware.
The available evidence is not consistent with a remote-access trojan (RAT).
There are no detected remote-control endpoints, outbound connection indicators, process-launch APIs, command execution indicators, persistence behavior, or suspicious remote-download activity. Static scanning cannot rule out every possible threat, but this report does not show the usual signs of a Minecraft RAT or backdoor.
| Class | Severity | Behavior | Evidence |
|---|---|---|---|
xerca.xercapaint.client.ModClient |
Low / needs context | Reads or enumerates local files; uses Base64 and cryptography APIs | onInitializeClient() uses Java NIO file and filesystem-enumeration APIs, plus a crypto API. |
xerca.xercapaint.packets.ImportPaintingPacketHandler |
Low / needs context | Uses local file APIs | Uses Java NIO file APIs, consistent with importing painting data or image files. |
The flagged classes are part of the JAR’s own xerca.xercapaint package rather than clearly identified bundled libraries. That makes the findings worth reviewing, but their names provide relevant context: a painting mod would reasonably need to import files and access local painting or image data.
The report does not identify file deletion, file encryption, mass file modification, credential-file targeting, or upload of local files to a remote destination.
No suspicious bundled third-party library classes were identified in this report.
No network activity indicators were found.
This does not prove the mod can never make a connection at runtime, but there is no static evidence here of hard-coded endpoints or recognized outbound connection behavior.
The scan coverage is strong:
No decompiler anomalies or failed classes were reported. This means there are no important code areas hidden from this scan due to parsing or decompilation failures. The report also does not show common static signs of heavy obfuscation, such as widespread decompiler failures or unusual archive contents.
This appears to be a Minecraft mod JAR, based on its name and class structure, including the client initialization class ModClient.
Its file access is plausible for a painting-related feature: the mod may need to browse, select, import, or save painting/image data locally. The class named ImportPaintingPacketHandler particularly supports that interpretation. However, users should still install mods only from the expected project page or trusted distribution channel, and verify that the downloaded file matches the release they intended to install.
No major red flags were identified in this scan.
The only unresolved point is the client class’s combination of filesystem enumeration and cryptography-related APIs. The report does not provide the surrounding source logic needed to prove exactly which files it accesses or why crypto is used. However, there is no accompanying evidence of network upload, credential collection, destructive file behavior, hidden downloads, or remote control.
4254a38e048697f60b16426077a834f1eedf366cc19cb668552ef01a6782e7b0.Static JAR scanning reduces risk by inspecting code and identifying known suspicious patterns, but it cannot prove a file is completely safe. It cannot fully predict runtime behavior, server-side behavior, interactions with other mods, or behavior triggered only under unusual conditions. A clean network result also means no recognized network indicators were found in this JAR; it is not an absolute guarantee that no connection can ever occur.
Yes. A Java JAR can contain malicious code, including code that steals data, downloads other files, executes commands, or contacts attackers. This report found no high-signal evidence of those behaviors in this JAR.
Use a JAR malware scanner, inspect its source or reputation where possible, download only from trusted publishers, compare checksums when available, and test unfamiliar mods in an isolated profile. For this file, all classes were successfully inspected and no network or RAT-like indicators were detected.
It can identify many common RAT-related signs, such as remote connections, command execution, persistence, hidden downloads, suspicious archive contents, and credential-theft patterns. This report does not show those signs, though no static scanner can guarantee detection of every threat.
No. Some developers obfuscate code for intellectual-property protection or to reduce copying. In this report, there were no decompiler failures or anomaly indicators suggesting that obfuscation prevented analysis.
Verdict: Mostly trust
Risk level: Low
Confidence: Moderate to high
Should I trust this JAR, and why? This JAR looks reasonably safe to use based on the available static scan evidence. Every class was successfully inspected, and the scan found no outbound connections, remote-control behavior, hidden downloads, process execution, credential theft, persistence, or destructive activity. The two flagged classes access local files, which is plausible for a Minecraft painting mod that imports or manages images. One class also uses Base64 and cryptography APIs, but the report provides no evidence that these are used to hide malicious behavior. Trust it most if it came from the legitimate project source and matches the version you intended to download.