[!WARNING] Final verdict available at the end of this report.
The scanner inspected all 41 classes in update.jar and successfully parsed and decompiled every one of them. It found 8 classes (about 19.5% of the JAR) with indicators that need manual review. The archive contains 460 methods and is relatively small at about 60 KB.
The most important findings are a custom class loader, reflection (code that inspects or calls other code dynamically), archive/file access, cryptographic decryption, and a method explicitly named loadPayloadFromDisk. One class also includes URL/network API use, although the scan found no actual domains, URLs, or IP addresses embedded in the JAR. These signals can sometimes be used by legitimate loaders or compatibility tools, but their purpose depends heavily on the surrounding code.
No high-signal malicious behavior was detected for credential theft, token grabbing, destructive process execution, persistence, or confirmed data exfiltration. The report does not show shell-command execution, browser/Discord credential collection, deletion logic, or hard-coded upload destinations.
However, the JAR contains code intended to decrypt and dynamically load a payload. Specifically, k7x.a.Agent has methods named decryptPayload, loadPayloadFromDisk, memoryInit, and nativeInit. This is not normal behavior for a simple Minecraft mod or plugin and makes it harder to determine what actually runs at runtime.
The report does not provide direct evidence of a remote-access trojan (RAT): no command-and-control host, remote command API, persistence mechanism, or explicit remote-control feature was identified.
That said, an encrypted payload combined with custom class loading is a serious transparency problem. Static scanning can inspect the visible loader code, but it may not be able to inspect code that is decrypted or loaded later.
The suspicious code appears to be part of the JAR’s own loader/bridge structure rather than clearly identified, common bundled libraries. The package names are short and unclear (k7x.a), and the class ab is in the default package, which makes attribution more difficult.
| Class | Severity | Behavior | Evidence |
|---|---|---|---|
k7x.a.Agent |
High | Decrypts and loads a payload; accesses files/archives; uses dynamic class loading and reflection; includes URL API use | decryptPayload(byte[]), loadPayloadFromDisk(ClassLoader), memoryInit(...), nativeInit(URLClassLoader) |
ab |
High | Custom class loader capable of defining/loading classes dynamically | defineAll(), findClass(...), loadClass(...) |
k7x.a.Bridge |
Medium | Uses reflection to connect code to game events and input/render hooks | onTick(), onRender(...), mouse, attack, item-use, and display-related methods |
sdk.UnsafeAccess |
Low–Medium | Uses reflection during initialization | Static initializer |
sdk.HotSpotPrior7u6StringHash |
Low–Medium | Uses reflection during initialization | Static initializer |
sdk.Maths |
Low–Medium | Uses reflection during initialization | Static initializer |
sdk.ModernCompactStringHash |
Low–Medium | Uses reflection during initialization | Static initializer |
sdk.ModernHotSpotStringHash |
Low–Medium | Uses reflection during initialization | Static initializer |
The Bridge class appears designed to forward Minecraft/game events such as ticks, rendering, attacks, item use, mouse input, and display updates to another dynamically selected component. Event hooks alone can be normal for a mod, but here they are paired with an encrypted payload loader.
The report does not identify known common third-party packages such as org.bstats, org.hsqldb, org.slf4j, Apache Commons, or HikariCP. The sdk.* classes may be an embedded low-level utility library, but the scan does not provide enough information to confirm their origin or purpose.
The reflection-only findings in the sdk.* classes are less concerning on their own than the k7x.a.Agent loader behavior.
java.net.URL).k7x.a.Agent includes both URL-related code and dynamic payload loading, the lack of visible destinations does not fully explain its network capability.This is good scan coverage: there were no decompiler errors or obvious decompiler-anomaly warnings preventing review of the visible classes.
However, successful decompilation does not make encrypted or dynamically loaded code visible. The decryptPayload and loadPayloadFromDisk methods are the main remaining blind spot, because they suggest additional code may be reconstructed and loaded at runtime.
This JAR appears to be Minecraft-related. Its code contains methods named findMinecraftClassLoader, game tick/render hooks, attack and item-use hooks, mouse handling, and display initialization.
Minecraft mods commonly use event hooks and sometimes reflection for cross-version compatibility. But a typical mod does not usually need to decrypt an unknown payload from disk and load it through a custom class loader. That combination is much more concerning than the normal game-event methods themselves.
k7x.a.Agent can decrypt a payload through decryptPayload(byte[]).loadPayloadFromDisk(...) indicates that code or data may be read from disk and loaded later.memoryInit(...) and nativeInit(...) suggest the payload may be initialized in memory or through a separate class loader.ab) that can define and load classes dynamically.40735600690bf2cb20aa9de411a92c4b11505acb78dc991dca0082a8428a674a.Static JAR scanning reduces risk by examining visible code and known API usage, but it cannot prove that a file is completely safe. This is especially important here because the JAR appears capable of decrypting and loading additional code at runtime. A static scan cannot fully assess code that is absent, encrypted, downloaded later, or created in memory.
Yes. A JAR can contain Java code that reads files, connects to the internet, loads additional code, or performs unwanted actions when the application runs it. A JAR file is not automatically malicious, but it should be treated like any executable software.
Check its source, publisher reputation, file hash, permissions/behavior, and scan results. For this JAR, the key concern is not a known malware signature but its ability to decrypt and dynamically load code that is not plainly visible.
It can identify common warning signs, such as suspicious network use, command execution, credential theft, persistence, and hidden loading behavior. This report does not confirm a Minecraft RAT, but it does identify hidden-payload loading behavior that warrants concern.
No. Obfuscation, reflection, or hard-to-read code can be used for legitimate protection or compatibility. In this report, the concern is the combination of those techniques with payload decryption and custom runtime class loading—not merely the use of reflection alone.
Verdict: Do not trust
Risk level: High
Confidence: Medium-High
Should I trust this JAR, and why? No, not based on this report. While the scanner found no direct proof of credential theft, remote control, destructive commands, or known malicious network destinations, the JAR contains an encrypted payload loader, file/archive access, and custom class-loading code. Those features can hide the real code that executes after the JAR starts, and they are not well explained by ordinary Minecraft mod functionality. The visible Minecraft event hooks may be legitimate, but the hidden-payload design is a major unresolved concern.